Les juristes ont été particulièrement rapides à adopter l’intelligence artificielle générative dans leurs pratiques. Le droit, matière reposant sur le langage, s’y prête particulièrement. Yannick Meneceur, magistrat qui a développé durant sa carrière une expertise liant le droit, l’informatique et la gestion administrative dans le secteur public, vient de publier un ouvrage intitulé IA générative et professionnels du droit, chez LexisNexis.

Dans cette interview, il nous livre une réflexion sur son usage par les juristes, avec une vision éclairée mais néanmoins critique. Selon lui, le recours à l’IAG, technologie dont l’impact sur le droit et ses pratiques est sans précédent, ne peut se faire sans une analyse des besoins et des risques. Une interview qui fait particulièrement écho au rapport d’information de la commission des lois du Sénat intitulé L’intelligence artificielle générative et les métiers du droit, rendue publique le 18 novembre dernier.

Les points clés à retenir

• L’IA générative s’impose rapidement dans les métiers du droit, notamment pour la rédaction, la recherche et la synthèse documentaire.
• Ces outils ne produisent pas une analyse juridique fiable par nature : ils reposent sur des probabilités linguistiques et peuvent générer des contenus inexacts.
• Les usages les plus pertinents concernent l’assistance aux juristes, et non leur remplacement.
• Des risques importants subsistent : biais des modèles, perte de contrôle sur les contenus, influence sur le raisonnement juridique et dépendance technologique.
• L’automatisation excessive peut fragiliser la formation des jeunes professionnels et appauvrir les mécanismes d’apprentissage du métier.
• L’intégration de l’IA dans le secteur juridique nécessite une gouvernance rigoureuse, fondée sur la supervision humaine, l’évaluation des risques et la maîtrise des outils utilisés.

 

L’IA générative : un outil prometteur mais imparfait pour les juristes

Sylvie Rozenfeld : La 2ème édition de l’étude Legal Professionals & Generative AI Global Survey qui vient de sortir révèle que l’utilisation de l’IA générative est en pleine expansion au sein des professions juridiques, malgré les incertitudes relatives à l’impact sur les pratiques et les métiers. Face à ce phénomène, la commission des lois du Sénat a, de son côté, lancé une mission d’information intitulée : « Intelligence artificielle et professions du droit », qui s’est achevée en novembre par la 89ème et dernière audition, celle de Clara Chappaz, ex-secrétaire d’Etat en charge de l’IA. La mission s’est concentrée sur les risques du recours aux systèmes d’intelligence artificielle générative pour les professionnels du droit, les mutations des conditions d’exercice de ces professions et les défis éthiques et déontologiques.

Vous êtes magistrat, inspecteur de la justice, vous avez travaillé 10 ans au Conseil de l’Europe, notamment sur les questions de l’IA et vous êtes auteur d’un précédent ouvrage L’intelligence artificielle en procès. Vous venez justement de publier un livre intitulé IA générative et professionnels du droit, qui n’est pas un mode d’emploi des SIAG à destination des juristes, même s’il comporte des conseils pratiques, mais un livre de vulgarisation au sens noble du terme et de réflexion sur les enjeux du recours à l’IA pour le secteur du droit. Vous êtes un juriste « geek », ce qui ne vous empêche pas d’être critique et de vous interroger sur la généralisation si rapide de cette technologie.

Les professionnels du droit sont de plus en plus nombreux à adopter l’IA générative dans leur pratique et le secteur des legaltech est particulièrement dynamique. Est-ce que, comme le disait Muriel Jourda, présidente de la commission des lois du Sénat et avocate, le droit, matière basée sur le langage, s’y prête particulièrement ?

Yannick Meneceur : À peu près toutes les organisations, publiques ou privées, se sont assez vite saisies du sujet de l’emploi des larges modèles de langage pour chercher à industrialiser la production de divers types d’écrits, qui paraissent tout à fait convaincants à première vue. Le domaine juridique n’a pas échappé à cet enthousiasme, avec une prolifération de solutions, essentiellement commerciales, promettant de transformer durablement les métiers du droit.

Mais être convaincant n’est pas être juste : si le langage produit ressemble très fortement à du langage juridique, une IA générative n’est pas un moteur de connaissance, ni un moteur de recherche. Même si on lui adjoint une base de données structurée pour servir de « tuteur », au moyen d’une approche RAG pour retrieval augmented generation, ces IA produisent ce que j’appelle une « langue des probables », en cherchant essentiellement à enchaîner de manière cohérente des mots par une approche mathématique, statistique et probabiliste.

Tous ceux qui ont testé ces IA génératives se sont rendu compte de « l’inventivité » de ces outils. Je parle d’inventivité pour ne pas utiliser le terme que je trouve impropre « d’hallucination », car il anthropomorphise trop cette technologie.

Pour le reformuler, nous avons affaire à des algorithmes permettant une production industrialisée de contenus, dont l’objectif n’est pas de produire quelque chose de vrai ou de juste mais seulement d’espérer que le modèle de langage a réussi à capturer, tel un chalutier drainant le fond, le raisonnement sous-jacent en même temps que sa formalisation. Tout cela n’est pas nouveau, puisque les performances des réseaux de neurones pour saisir des motifs récurrents dans de grands jeux de données ont permis des performances tout à fait saisissantes : jouer au jeu de Go par exemple ou reconnaître une image. Mais, pour les larges modèles de langage, cette propension à générer coûte que coûte du contenu n’est pas un « bug », mais bien une fonctionnalité. Cela ne veut toutefois pas dire que nous n’allons pouvoir ne rien en faire.

Quels usages concrets de l’IA générative dans les métiers du droit ?

S.R. : Pour quels usages ?

Y.M. : Je pense que certains opérateurs se sont trop vite concentrés sur des cas d’usage trop simplistes ou leur paraissant trop évidents : moins que l’emploi brut de ces IA génératives pour rédiger des textes à la place des juristes, il faut plutôt parvenir à se projeter sur l’utilité de cette nouvelle « brique » dans des systèmes hybrides.

Utiliser une couche conversationnelle basée sur un large modèle de langage avec un vrai moteur de recherche juridique par exemple, automatiser l’interaction entre plusieurs applications métiers avec un large action model, améliorer l’interaction avec un arbre de décision pour choisir des paragraphes prérédigés de rédaction sont autant de possibilités à explorer.

D’autres applications commencent par ailleurs à faire consensus comme le speech to text, c’est-à-dire de la transcription de captation audio vers du texte. C’est d’ailleurs probablement la première application qui va entrer dans les tribunaux en France, pour aider à transcrire des auditions par exemple.

L’interprétation ou la traduction sont des sujets plus délicats en matière juridique : si ces outils peuvent « dépanner » des professionnels maîtrisant déjà convenablement une autre langue, la précision indispensable dans certaines circonstances pouvant avoir des conséquences juridiques substantielles sur les individus continuera de justifier l’intervention d’interprètes ou de traducteurs assermentés.

Les résumés de quantités importantes de documents sont également souvent cités comme une aide utile pour les juristes. Une attention particulière est à porter sur la qualité de ces résumés, parfois trop généraux ou avec des contenus inexacts et devant être repris pour constituer une réelle valeur ajoutée.

Enfin, parmi les cas d’usage pouvant encore être cités, il peut être mentionné l’automatisation de la veille juridique, la recherche de cohérence ou d’incohérence entre divers textes, comme des divergences de jurisprudence, la recherche de nullités de procédures, ou encore l’aide à la rédaction.

Sur ce dernier point, beaucoup de précautions sont à prendre car des études ont démontré l’influence que ces systèmes pouvaient avoir sur la manière de rédiger. Une étude de l’université de Cornell a documenté par exemple la manière dont des personnes disposant d’une aide automatisée à la rédaction se trouvaient influencées par les propositions du système.

Un autre élément important à soulever est l’influence d’un type de système juridique qui peut être embarqué dans un système de langage. Avec des modèles majoritairement entraînés sur de l’anglais et des représentations de common law, il va être assez compliqué de l’empêcher de s’en défaire totalement dans les mécanismes sous-jacents.

 

Les risques liés à l’automatisation du raisonnement juridique

S.R. : Même si on nourrit le système avec des bases de données de jurisprudence de droit continental ?

Y.M. : Je parle ici de l’emploi de larges modèles de langage open source courants, qui peuvent servir de cœur à des systèmes plus spécialisés. L’on maîtrise en réalité peu, voire pas du tout, les données ayant servi à constituer ces modèles. Les modèles d’origine anglo-saxonne embarquent à coup sûr massivement des informations récoltées sur internet, en langue anglaise, embarquant des biais culturels tout à fait naturels.

Avec d’autres modèles, plus confidentiels pour l’instant, entraînés avec des données mieux sélectionnées et plus représentatives, les risques peuvent en effet être réduits. Mais plus que des suppositions, nous avons besoin de manière urgente de métriques et de benchmarks pour parvenir à évaluer de manière objective la performance de ces systèmes en exploitation.

Je ne cesse d’être surpris de la manière dont nous nous sommes accommodés de l’approximation à l’époque de l’IA, que j’avais qualifiée dans mon premier ouvrage L’intelligence artificielle en procès d’ère de l’approximation : après des décennies de très hautes exigences envers les systèmes informatiques en production dans des domaines sensibles, j’ai l’impression que les promesses de l’apprentissage automatique, si enthousiasmantes, ont conduit à une tolérance assez inexplicable.

L’idée que l’adjonction continue de données parviendrait à améliorer progressivement les modèles est encore fortement ancrée. Or, non. L’augmentation du nombre d’observations entraîne parfois, paradoxalement, une chute de la performance des systèmes. C’est un peu comme si on avait inventé un moteur révolutionnaire pour les voitures, mais qui exploserait de manière aléatoire. Qui accepterait aujourd’hui de les voir se déployer dans l’espace public ?

Donc, pour des professions comme la justice ou la santé où il importe de produire des informations justes, on prend aujourd’hui le risque d’introduire ces systèmes de manière massive en ayant une capacité de contrôle assez faible et en reportant sur les utilisateurs la charge de les corriger.

Ce constat n’est pas un propos de défiance vis-à-vis de cette technologie. Mais, comme avec tout autre produit commercial, il faut se poser les bonnes questions : est-ce une solution adaptée à mon besoin ? Et si oui, comment l’implémenter et avec quelles précautions sur la base d’éléments objectivables ?

S.R. : Et pour quelle plus-value ?

Y.M. : Pour valable que soit la fameuse courbe de Gartner, il faut reconnaître que nous sortons à peine de la période d’emballement, qui va très probablement nous conduire à une période d’intenses déceptions : j’ai l’impression que l’on voit des projets d’IA partout mais que l’on peine à faire émerger le cas d’usage qui sera le réel game changer.

Je m’interroge si cette plus-value ne sera pas à trouver du côté des interfaces conversationnelles plus que dans la production. Notre manière d’interagir avec une machine n’a pas fondamentalement changé depuis l’émergence des systèmes d’exploitation graphiques des années 80. Les larges modèles de langage nous ouvrent la possibilité de converser de manière tout à fait naturelle.

Réserver un billet de train ou d’avion pourrait ne plus se réaliser en une cinquantaine de clics, et parfois un peu d’énervement, mais avec une simple demande orale contenant les informations nécessaires. Rechercher une jurisprudence, accéder à un modèle de document ou automatiser le traitement de certains emails pourrait s’effectuer avec la même simplicité.

S.R. : Cela existe déjà avec les assistants personnels intelligents ?

Y.M. : Ils ne vont pas si loin. Qu’il s’agisse de l’assistant Google, de Siri, d’Alexa ou d’autres, des automatisations sont possibles, mais avec encore d’immenses approximations. Ce n’est pas pour rien si Apple Intelligence s’est intéressé à ChatGPT.

Le gain est similaire à celui des dictées vocales. Rappelons-nous des premières dictées vocales dans les années 90 et les résultats que nous obtenons aujourd’hui. Tout comme nous nous sommes habitués aux correcteurs orthographiques à l’intérieur des traitements de texte, on pourrait également avoir des systèmes d’IA totalement intégrés, tirant parti de nos précédentes rédactions, de nos contextes de rédaction et qui nous proposeraient des textes dans notre style.

Cette hyperpersonnalisation m’apparait être une réelle attente de professionnels, notamment en droit, qui souhaitent conserver un haut degré d’autonomie dans leurs productions écrites. Tout en se laissant la possibilité d’y appliquer ensuite un « style », pour uniformiser le ton si besoin.

Cet exercice de prospective trouve naturellement des limites : les jeunes professionnels ou les profanes d’un domaine ne pourront vraisemblablement pas pallier leur manque de connaissances. À titre personnel, je tente de former mes étudiants en droit dans ce sens : ils constatent bien par la pratique que la production par des IA génératives demeure, au mieux, relativement banale et sans relief. C’est en se forgeant d’abord une bonne expérience de juriste qu’ils parviendront à en tirer le meilleur parti.

Formation des juristes : quels impacts sur l’apprentissage du métier ?

S.R. : Dans votre livre, vous évoquez le fait que l’IA générative permet de se délester des tâches répétitives ou à faible valeur ajoutée pour se consacrer à la partie la plus intellectuelle ou créative du raisonnement juridique. Est-il vraiment souhaitable de s’en passer ? N’est-ce pas un moyen pour les jeunes d’intégrer le métier, de sédimenter la connaissance ? Ces tâches ne participent-elles aussi à l’émergence de la créativité, voire de la sérendipité, autrement dit ne risque-t-on un formatage du raisonnement ?

Y.M. : Quand on entre dans une profession, je l’ai connu dans les métiers de greffier et de magistrat, on commence souvent par effectuer des tâches un peu ingrates. Mais il se joue davantage que l’exécution de la tâche. Il y a de l’observation, un retour des professionnels sur ce qu’on réalise, ce qui fait que lorsqu’on se retrouve en pleine responsabilité, les connaissances se sont sédimentées dans le temps.

Pour le dire autrement, dans l’expérience de compagnonnage, c’est aussi du savoir-être qui se transmet. Je crains donc que les organisations qui misent sur la suppression massive de stagiaires et jeunes professionnels risquent de perdre un « sas » important et de se retrouver face à des jeunes professionnels dont ils ne comprendront pas les performances médiocres et imputer cette situation à des questions de génération ou à une baisse du niveau universitaire.

L’IA générative peut-elle transformer durablement la justice ?

S.R. : Contrairement à certains préjugés, la technologie n’est pas qu’un outil, elle n’est pas neutre et elle a une influence sur la construction des sociétés. Quelle pourrait être l’influence de l’IA générative sur le droit ? Peut-elle le transformer ?

Y.M. : Ces systèmes d’IA ont en effet déjà la potentialité d’exercer une influence majeure sur les individus et la société. Je pense que le droit est face à un réel enjeu de survie. Dans mon premier ouvrage, j’avais déjà partagé les travaux d’Antoinette Rouvroy et Thomas Berns sur la gouvernementalité algorithmique, c’est-à-dire la substitution du droit par le calcul.

L’idée à garder en tête c’est que nous ne nous trouvons pas face à une rupture nette, une sorte de « coup d’État », mais à quelque chose qui est de l’ordre du glissement. En multipliant les micro-mécanismes décisionnels partout, on introduit en réalité autant de chevaux de Troie qui peuvent être manipulés et influencer, volontairement ou non, leurs utilisateurs.

La place des réseaux sociaux dans les interférences électorales ne nous raconte pas autre chose. Une production juridique qui s’appuierait sur un modèle de langage commun déléguerait un pouvoir immense au concepteur de ce modèle : des contrepouvoirs sérieux devront être mis en place pour s’assurer qu’il ne dirige pas ses utilisateurs vers telle ou telle rédaction.

J’ai aussi exploré dans une étude récente intitulée Intelligence artificielle, État de droit et œuvre de justice : regard prospectif sur l’évolution de la justice à l’ère de l’hyperindividualisme et de la transition numérique, publiée par Lexbase, la manière dont notre système juridique risque de se trouver éclaté en autant de sous-systèmes de règlements de litiges, potentiellement automatisés, venant résoudre les conflits nés de l’exécution de telle ou telle prestation avec des fournisseurs de biens ou services.

L’on préfèrera probablement une solution automatisée immédiate, même moins satisfaisante, que porter la contestation devant une instance judiciaire. Or, on le voit avec les litiges en matière de consommation, moins que la réparation individuelle et ponctuelle d’un dommage, la justice joue également un rôle de rééquilibre des asymétries de notre société.

S.R. : Pensez-vous que l’IA générative puisse provoquer un risque de bipolarisation entre avocats : en creusant les écarts entre ceux qui l’utilisent et les autres ?

Y.M. : Dans l’esprit de l’évolution que je viens d’évoquer, je crois que l’utilisation de divers systèmes automatisés risque plutôt de faire naître une justice privée de masse, expéditive et automatisée, qui produira des solutions plus ou moins satisfaisantes, versus une justice qui s’adressera aux justiciables qui auront les moyens de se payer le temps d’un procès.

Évidemment, dans le temps de la transition technologique, ceux maîtrisant plus rapidement des systèmes leur faisant gagner en efficacité auront un avantage. Mais une fois banalisée et l’égalité des armes acquise, c’est une tout autre fracture qui s’opèrera.

L’intégralité de l’interview est à retrouver dans le n°508 de la revue Expertises des systèmes d’information.

Propos recueillis par Sylvie Rozenfeld

 

Exergues

On prend aujourd’hui le risque d’introduire ces systèmes de manière massive en ayant une capacité de contrôle assez faible et en reportant sur les utilisateurs la charge de les corriger. Les organisations qui misent sur la suppression massive de stagiaires et jeunes professionnels risquent de perdre un « sas » important et de se retrouver face à des jeunes professionnels dont ils ne comprendront pas les performances médiocres. Le vrai défi, de nature politique, sera de réinvestir les éventuels gains d’efficacité vers un meilleur accompagnement humain et personnalisé plutôt que de supprimer des emplois.

L’exemple du tribunal de commerce de Paris ou celui de la Cour de cassation nous montre que l’identification des usages à forte valeur ajoutée va émerger des praticiens. Anticiper dès le départ la manière de remplacer un tel système voire de s’en passer.

 

À propos

Yannick Meneceur est magistrat et a développé durant sa carrière une expertise liant le droit, l’informatique et la gestion administrative dans le secteur public. Il a notamment travaillé pendant dix ans au Conseil de l’Europe sur les questions liées à l’intelligence artificielle et au numérique.

Il est l’auteur de plusieurs ouvrages consacrés aux enjeux juridiques et sociétaux de l’IA, dont L’intelligence artificielle en procès, et vient de publier IA générative et professionnels du droit chez LexisNexis.

La continuité d’exploitation des logiciels constitue un enjeu structurant dans les relations contractuelles entre éditeurs et utilisateurs. En cas de défaillance du fournisseur, l’accès au code source, à la documentation ou aux éléments techniques devient un point déterminant pour assurer la poursuite des opérations.

Dans ce contexte, la clause d’accès proposée par l’Agence pour la protection des programmes (APP) s’inscrit comme un mécanisme contractuel permettant d’organiser cet accès de manière encadrée. Souvent intégrée aux contrats logiciels, elle soulève néanmoins de nombreuses interrogations, tant sur sa portée juridique que sur ses conditions de mise en œuvre.

Cette FAQ apporte un éclairage précis sur le fonctionnement de la clause d’accès APP, ses modalités de validité et ses limites au regard d’un contrat d’entiercement.

Les points clés à retenir sur la clause d’accès de l’APP

• La clause d’accès permet à un bénéficiaire d’accéder à un dépôt APP en cas de défaillance du fournisseur.
• Elle doit impérativement faire l’objet d’une souscription auprès de l’Agence pour la Protection des Programmes.
• Elle offre un niveau de sécurité inférieur à un contrat d’entiercement tripartite.
• Le fournisseur doit être membre de l’APP pour pouvoir souscrire.
• Le nombre de bénéficiaires est limité à cinq par clause.
• Une attestation permet de prouver l’existence et la validité de la clause.

Définition et principes de la clause d’accès

Qu’est-ce qu’une clause d’accès ?

Une clause d’accès est un service d’entiercement permettant à un ou plusieurs bénéficiaires d’accéder au dépôt réalisé par le fournisseur auprès de l’APP si l’un des cas d’accès prévus au contrat principal signé entre le fournisseur et le bénéficiaire se produit.

Quelle est la différence entre une clause d’accès et un contrat d’entiercement tripartite ?

Une clause d’accès est une clause à intégrer à un contrat principal, par exemple un contrat de développement, de licence ou de maintenance, conclu entre le fournisseur, titulaire des droits sur la solution entiercée, et un bénéficiaire. L’APP n’est pas relecteur de la clause.

Le contrat d’entiercement tripartite est un contrat secondaire au contrat principal, signé entre le fournisseur, le bénéficiaire et l’APP. L’APP est partie au contrat et accompagne le fournisseur et le bénéficiaire dans la mise en œuvre du contrat d’entiercement. L’APP est également le dernier relecteur de la version finale du projet de contrat d’entiercement afin de valider les clauses du contrat avant la mise en signature.

Quel est l’intérêt d’une clause d’accès dans un contrat logiciel ?

La clause d’accès permet à un bénéficiaire de pouvoir accéder au dépôt réalisé à l’APP par le fournisseur si l’un des cas d’accès mentionnés survient. La clause d’accès garantit ainsi au bénéficiaire une continuité d’activité en cas de défaillance du fournisseur.

Dans quels cas utiliser une clause d’accès APP plutôt qu’un contrat d’entiercement tripartite ?

La clause d’accès est plus rapide à mettre en place. Néanmoins, elle offre au bénéficiaire un niveau de sécurité inférieur à celui d’un contrat d’entiercement tripartite.

En effet, dans le cadre d’un contrat d’entiercement, l’APP, en sa qualité de partie au contrat, valide la version finale afin de s’assurer de la conformité des clauses, ce qui n’est pas le cas pour une simple clause d’accès.

Une clause d’accès peut toutefois constituer un mécanisme d’entiercement suffisant, à condition qu’elle soit rédigée de manière complète par le fournisseur et le bénéficiaire, et que les cas d’accès prévus soient clairement définis et aisément vérifiables.

Validité juridique et conditions de conformité

Quelles conditions doivent être remplies pour qu’une clause d’accès APP soit valable ?

Une clause d’accès ne peut entrer en vigueur que si le fournisseur a souscrit la clause d’accès auprès du service juridique de l’APP. À la suite de cette souscription, un mail de confirmation est envoyé par le service juridique de l’APP au fournisseur.

Une clause d’accès est-elle valable si elle est simplement incluse dans un contrat ?

Non, une clause d’accès n’est valable que si elle a été souscrite auprès du service juridique de l’APP.

En conséquence, aucun accès ne pourra être accordé par la Commission d’accès de l’APP si une clause d’accès est mentionnée dans le contrat principal conclu entre le fournisseur et le bénéficiaire sans avoir fait l’objet d’une souscription auprès du service juridique de l’APP.

Le fournisseur doit-il être membre de l’APP pour pouvoir souscrire à une clause d’accès ?

Le fournisseur, titulaire des droits sur la solution objet de l’entiercement, doit être membre de l’APP afin de pouvoir bénéficier des services de l’APP. Ainsi, si le fournisseur n’est pas membre de l’APP, il ne pourra ni effectuer de dépôt ni souscrire à une clause d’accès.

Combien de bénéficiaires une clause d’accès APP peut-elle désigner ?

Il est possible de désigner jusqu’à cinq bénéficiaires par clause d’accès souscrite. Par exemple, si pour une même clause d’accès un fournisseur souhaite désigner quinze bénéficiaires, il sera nécessaire de souscrire trois clauses d’accès pour la même œuvre.

La clause d’accès APP doit-elle être renouvelée chaque année ?

Une clause d’accès est souscrite pour une période initiale de deux ans, puis renouvelée par tacite reconduction chaque année, sauf demande de résiliation du fournisseur, laquelle devra respecter les conditions prévues à l’article 5.1.a du Règlement général de l’APP.

 

Mise en place opérationnelle et gestion de la clause

Qui souscrit la clause d’accès auprès de l’APP ?

Le fournisseur, titulaire des droits sur la solution objet du dépôt, doit souscrire une clause d’accès auprès de l’APP.

L’APP valide-t-elle ou modifie-t-elle la clause d’accès ?

L’APP n’intervient pas en tant que relecteur de la clause d’accès et n’en valide donc pas le contenu. Néanmoins, le service juridique de l’APP peut, sur demande adressée par courriel à l’adresse legal@app.asso.fr, transmettre des modèles de clauses à insérer dans le contrat.

Comment souscrire à une clause d’accès auprès de l’APP ?

Il existe deux manières de souscrire à l’offre « gestion d’une clause d’accès » de l’APP :

• Si le dépôt initial, objet de la clause d’accès, n’a pas encore été réalisé : il est possible de sélectionner l’option « clause d’accès » directement lors du dépôt initial standard sur votre espace membre.
• Si le dépôt initial, objet de la clause d’accès, a déjà été réalisé : il suffit d’adresser un email au service juridique de l’APP à l’adresse legal@app.asso.fr afin qu’un juriste de l’APP puisse procéder à la souscription de la clause d’accès. Votre demande devra idéalement comprendre votre numéro de membre APP, ainsi que le nom et le numéro IDDN de l’œuvre concernée par la clause d’accès.

Une même clause d’accès peut-elle être insérée à plusieurs contrats ?

Il est en effet possible de prévoir une même clause d’accès portant sur la même œuvre dans plusieurs contrats principaux. Néanmoins, chaque clause d’accès souscrite est limitée à un nombre de cinq bénéficiaires maximum sur la même œuvre.

Quels sont les coûts associés à une clause d’accès APP ?

Une clause d’accès est facturée 450 € HT par an, dans la limite de cinq bénéficiaires désignés, hors cotisation annuelle obligatoire pour devenir membre.

Sécurité et risques

La clause d’accès APP est-elle aussi sécurisée qu’un contrat tripartite ?

La clause d’accès offre au bénéficiaire un niveau de sécurité inférieur à celui d’un contrat d’entiercement tripartite.

En effet, dans le cadre d’un contrat d’entiercement, l’APP, en sa qualité de partie au contrat, valide la version finale afin de s’assurer de la conformité des clauses, ce qui n’est pas le cas pour une simple clause d’accès.

Par ailleurs, dans le cadre d’une clause d’accès, l’APP n’adressera pas au fournisseur de notifications de rappel l’invitant à effectuer les mises à jour du dépôt.

Quels sont les risques si une clause d’accès n’a pas été souscrite auprès de l’APP ?

Si une clause d’accès n’est pas souscrite auprès de l’APP, toute demande d’accès effectuée par un bénéficiaire sera refusée par la Commission d’accès de l’APP, et cela même si la clause d’accès a bien été insérée au contrat principal signé entre le fournisseur et le bénéficiaire.

 

Vérification et preuve

Comment, en tant que bénéficiaire, puis-je vérifier si une clause d’accès a bien été souscrite ?

Afin de vous assurer que le fournisseur a bien souscrit la clause d’accès mentionnée dans le contrat principal, et qu’ainsi vous bénéficiez d’un droit d’accès si l’un des cas d’accès mentionné au contrat survient, nous vous invitons à demander au fournisseur une attestation clause d’accès.

Que contient une attestation clause d’accès ?

L’attestation clause d’accès est un document délivré par le service juridique de l’APP et signé par le Président de l’APP. Elle atteste qu’une clause d’accès est en vigueur pour l’œuvre concernée au titre de l’année en cours. Cette attestation est nominative et mentionne notamment l’identité de l’entité bénéficiaire de la clause.

Aller plus loin : clause d’accès et entiercement logiciel

La clause d’accès constitue un mécanisme contractuel permettant d’organiser l’accès aux éléments déposés auprès de l’Agence pour la protection des programmes dans des situations définies.

Sa mise en œuvre suppose une attention particulière quant à sa souscription effective, à la rédaction des cas d’accès et à son articulation avec les autres dispositifs contractuels existants, notamment l’entiercement.

Pour en savoir plus sur la clause d’accès ou les solutions d’entiercement logiciel, contactez-nous ici.

À propos de l’auteur

Marina Chanian est juriste en propriété intellectuelle à l’Agence pour la protection des programmes (APP). Elle est spécialisée dans les problématiques liées à l’entiercement logiciel et accompagne les entreprises dans la sécurisation de leurs actifs numériques et de leurs relations contractuelles.

Une étude commandée par la DG CNECT de la Commission européenne offre un éclairage sur les orientations politiques et les choix stratégiques en matière de futures réglementations concernant l’économie fondée sur les données. Prospective et bonnes pratiques.

L’économie européenne des données connaît une mutation profonde, portée par l’essor de l’intelligence artificielle générative (IAG) et la nécessité croissante de conformité réglementaire, notamment en termes de protection des données à caractère personnel, de droit d’auteur et du respect des libertés et droits fondamentaux.

Une étude publiée en décembre et commandée par la Commission européenne met en lumière les enjeux juridiques et stratégiques de l’économie fondée sur les données. Il est toujours intéressant, en matière de prospective sur l’évolution du cadre réglementaire européen du numérique, d’examiner avec attention les études commandées par la Commission européenne, notamment par la DG CNECT, car elles offrent un éclairage précieux sur les orientations politiques et les choix stratégiques.

L’étude « sur les frontières des données à venir : l’IA générative, la conformité réglementaire et les dimensions internationales » explore l’évolution de l’économie des données, à travers trois axes : les besoins en données pour l’innovation et le rôle des données synthétiques ; l’utilisation de méthodes automatisées de conformité ; et la conciliation des approches internationales en matière de gouvernance des données.

Les points clés à retenir

• L’économie européenne des données est en transformation sous l’effet de l’intelligence artificielle générative et du renforcement des exigences réglementaires.
• L’Union européenne fait face à un enjeu de souveraineté numérique, notamment en matière d’accès à des données de qualité.
• La Stratégie pour une Union des données vise à faciliter l’accès à des données sectorielles et à encourager l’usage de données synthétiques.
• L’adoption des outils automatisés de conformité réglementaire reste hétérogène entre grandes entreprises et PME.
• La gouvernance des données en Europe repose sur une approche fondée sur les droits fondamentaux.
• Les organisations doivent mettre en place une gouvernance structurée des données intégrant gestion des risques et cybersécurité.

L’économie des données : un enjeu de souveraineté numérique européenne

Les auteurs de l’étude considèrent que, malgré une production scientifique significative, l’Union européenne demeure en retrait par rapport aux États-Unis et à la Chine en matière de développement de modèles fondamentaux et d’investissements. Le principal défi identifié est l’accès à des données de haute qualité, multilingues et sectorielles.

Pour les entreprises européennes d’IAG, les coûts d’acquisition, de traitement et de gestion des données représentent une charge souvent trop élevée, notamment en raison des frais de licence.

Pour soutenir l’innovation et la souveraineté numérique européenne, la Stratégie pour une Union des données (19 novembre 2025) vise à garantir l’accès à des données de qualité et à développer les espaces européens communs de données. Elle encourage également l’usage de données synthétiques, plus respectueuses de la vie privée.

Systèmes automatisés pour la conformité réglementaire : une adoption inégale

L’adoption des outils automatisés de conformité dans des secteurs critiques comme l’énergie, l’agriculture et la santé reste inégale.

Les grandes organisations utilisent des systèmes avancés (ERP, registres digitaux), permettant une traçabilité accrue des données. À l’inverse, les PME utilisent encore des méthodes traditionnelles, ce qui augmente les risques d’erreurs et la charge administrative.

Les obstacles identifiés sont principalement techniques et financiers : coûts élevés et manque d’interopérabilité des outils.

L’incarnation des valeurs européennes dans la gouvernance des données

L’étude analyse plusieurs modèles internationaux de gouvernance des données : approche fondée sur les droits (UE, avec le RGPD), approche de marché (États-Unis), approche étatique (Chine) ou hybride (Japon).

L’enjeu pour l’Union européenne est de développer une économie des données respectant les droits fondamentaux, tout en favorisant l’innovation et en préservant la souveraineté des données.

Cela implique de renforcer le cadre réglementaire européen et de consolider son rôle de référence internationale, notamment via les décisions d’adéquation et la régulation des flux internationaux de données.

Recommandations et bonnes pratiques

L’analyse de cette étude doit guider les organisations à adopter des pratiques adaptées :

• Mettre en place une gouvernance de la donnée intégrant cybersécurité, IA et conformité.
• Former les équipes aux enjeux de réglementation, cybersécurité et propriété intellectuelle.
• Se faire accompagner pour la mise en conformité (Règlement IA, Data Act, etc.) et la sécurisation des usages.
• Évaluer et documenter les risques liés à l’IA et aux données.
• Réaliser des audits réguliers pour assurer la conformité et adapter les politiques internes.

Il est primordial pour les organisations d’effectuer une veille réglementaire continue et d’adopter une stratégie intégrant une gouvernance responsable des données, afin de renforcer leur résilience dans un environnement numérique en constante évolution.

 

A propos de l’auteure

Eva ASPE est responsable des Affaires publiques et européennes chez Mathias Avocats, avec une expertise en droit du numérique et droit européen et international (IA, data & cybersécurité). Elles est coauteures avec François Gorriez et Garance Mathias de l’ouvrage récemment publié « IA, Cybersécurité, Data : Garantir votre conformité numérique » éditions Lexis Nexis.

L’intelligence artificielle s’est déjà installée dans les usages professionnels. L’enjeu est donc de structurer un cadre de maîtrise permettant de sécuriser les usages, d’anticiper les risques et de renforcer la confiance. Pour les entreprises, la difficulté n’est pas uniquement technique : elle est aussi juridique, organisationnelle et contractuelle. L’intelligence artificielle n’est plus un sujet prospectif. Elle s’est installée dans le quotidien des entreprises, parfois de manière visible, parfois plus diffuse, au travers d’outils utilisés par les équipes métiers, les fonctions support, les directions techniques, juridiques ou les prestataires. Création de contenus, analyse de données, assistance à la rédaction, automatisation, développement, relation client : l’IA est déjà là, avec une promesse concrète de gain de temps, de productivité et de transformation. Mais cette promesse n’est pas sans contrepartie. Lorsqu’elle est utilisée sans cadre clair, sans validation préalable ou sans contrôle suffisant, l’IA devient un facteur d’exposition supplémentaire pour l’entreprise. Risques juridiques, fuites de données, incertitudes sur les droits de propriété intellectuelle, biais, dérives réputationnelles : la question n’est plus de savoir s’il faut s’emparer du sujet, mais à quel niveau de maturité l’entreprise choisit de le traiter.

 

Les points clés à retenir sur la gouvernance de l’IA

• L’IA est déjà largement déployée dans les entreprises, souvent sans encadrement formalisé.
• Les risques sont multiples : propriété intellectuelle, données personnelles, cybersécurité, responsabilité et réputation.
• Le règlement sur l’intelligence artificielle s’ajoute à un cadre juridique existant déjà dense (RGPD, droit d’auteur, etc.).
• La gouvernance IA doit partir des usages réels et s’appuyer sur une cartographie précise.
• Une approche transverse impliquant juridique, IT, sécurité et métiers est nécessaire.
• Les leviers principaux sont la charte IA, la contractualisation et la formation des équipes.

 

Un corpus de règles déjà dense, au-delà du seul règlement sur l’intelligence artificielle (« RIA »)

Les entreprises qui utilisent des systèmes d’intelligence artificielle sont déjà confrontées à un ensemble dense de règles applicables, indépendamment même du règlement sur l’intelligence artificielle. Le RGPD et la loi Informatique et Libertés trouvent à s’appliquer dès lors que les outils mobilisés traitent des données à caractère personnel, notamment dans les prompts, les historiques d’usage, les bases d’entraînement ou les contenus générés. Le droit de la propriété intellectuelle encadre, quant à lui, les données exploitées, les contenus reproduits, les créations générées et les droits attachés aux livrables. Selon les cas d’usage, le droit pénal, le droit de la consommation, les obligations en matière de cybersécurité ou encore certaines réglementations sectorielles peuvent également être mobilisés. Le règlement sur l’intelligence artificielle vient donc compléter ce paysage, non s’y substituer. Son apport majeur est d’introduire un cadre spécifiquement dédié à l’intelligence artificielle, structuré autour d’une approche par les risques. Selon la qualification du système concerné et le rôle occupé par l’entreprise dans la chaîne de valeur — fournisseur, déployeur, distributeur ou importateur — les obligations ne seront pas les mêmes et pourront porter sur la documentation, la traçabilité, l’information, l’évaluation des risques, la gouvernance ou encore la formation. Cette logique impose d’anticiper. La conformité en matière d’IA suppose une lecture croisée des usages, des flux, des outils, des responsabilités et des exigences applicables.

 

Les principaux risques liés à l’utilisation de l’IA

Avant de structurer une gouvernance adaptée, il est nécessaire d’identifier les principaux risques auxquels l’entreprise est exposée.

Propriété intellectuelle et titularité des droits

Le premier point de vigilance concerne la propriété intellectuelle. Le risque se situe à plusieurs niveaux : dans les données d’entraînement utilisées par les éditeurs, dans les données ou contenus injectés en entrée par les utilisateurs, et dans les résultats générés en sortie. Une entreprise peut ainsi être exposée à des actions en contrefaçon ou à des revendications sur des contenus protégés si elle exploite ou diffuse des résultats produits dans des conditions juridiquement incertaines.

À cela s’ajoute une difficulté devenue centrale : celle de la protection des contenus générés par IA. En droit français, un contenu généré sans intervention humaine suffisamment caractérisée ne relève pas, en principe, de la protection par le droit d’auteur. L’entreprise doit donc être en mesure d’identifier la place exacte de l’intervention humaine dans ses processus de création, de validation ou de réutilisation.

Données personnelles et conformité réglementaire

La deuxième zone de risque est réglementaire, en particulier au regard de la protection des données personnelles. L’utilisation d’un outil d’IA dans un cadre professionnel n’est jamais neutre lorsqu’elle implique des données relatives à des salariés, des clients, des prospects, des candidats, des patients ou des utilisateurs. Les principes de minimisation, de sécurité, de licéité, de limitation des finalités et de maîtrise des durées de conservation doivent être respectés.

Or, dans les usages réels, les pratiques des équipes vont souvent plus vite que les règles internes. Des informations sensibles peuvent être intégrées dans des prompts, des données peuvent transiter vers des environnements non validés, et des traitements peuvent être mis en œuvre sans véritable cartographie ni cadre de gouvernance.

Cybersécurité et responsabilité

Le troisième risque touche à la responsabilité, à la sécurité et à la cybersécurité. De nombreux outils d’IA, en particulier générative, sont déployés sur la base de conditions générales standardisées, avec peu de garanties sur la confidentialité, la non-réutilisation des données ou la robustesse des environnements.

Lorsque des collaborateurs utilisent des versions publiques ou non validées d’outils d’IA, l’entreprise peut s’exposer à des fuites de données confidentielles, à des atteintes au secret des affaires ou à des vulnérabilités exploitables. Le sujet ne relève donc pas uniquement de l’IT : il engage directement la direction, le juridique, la sécurité et les métiers.

Risques éthiques et organisationnels

Le quatrième risque est éthique et organisationnel. Les systèmes d’IA peuvent produire des biais, des hallucinations, des résultats trompeurs ou des effets discriminatoires. Dans certains usages, notamment lorsqu’une décision automatisée ou assistée par l’IA a un impact significatif sur une personne, les conséquences peuvent être particulièrement sensibles : recrutement, évaluation, orientation, détection de fraude ou hiérarchisation des candidatures.

Une entreprise qui ne met pas en place de garde-fous suffisants s’expose non seulement à un risque de non-conformité, mais aussi à une perte de confiance interne et externe. À cela s’ajoute une dimension de plus en plus présente dans les politiques RSE : l’impact environnemental de certains systèmes d’IA, qui interroge les critères de sobriété et de déploiement responsable.

Risque réputationnel

Enfin, le risque réputationnel ne doit jamais être traité comme accessoire. Une fuite de données, un usage mal encadré, une communication trompeuse sur le recours à l’IA, un résultat faux ou biaisé diffusé à l’extérieur peuvent rapidement devenir un sujet d’image. En pratique, le risque réputationnel est souvent le point de convergence des autres : une faiblesse juridique, technique ou éthique devient une crise de confiance.

 

Gouvernance IA : partir des usages réels de l’entreprise

La tentation est grande, pour les entreprises, de commencer par rédiger une charte IA ou d’annoncer la création d’un comité dédié. Ces outils peuvent être utiles, mais ils n’ont de valeur que s’ils reposent sur une compréhension réelle des usages.

Cartographier les usages

La première étape consiste à cartographier les cas d’usage existants ou envisagés. Quels outils sont déjà utilisés ? Par quelles équipes ? Pour quelles finalités ? Avec quelles données ? Dans quels environnements ? Avec quels prestataires ? Cette photographie des usages réels est indispensable pour sortir d’une logique théorique. Une gouvernance efficace ne peut pas être plaquée ; elle doit être construite à partir des pratiques concrètes de l’entreprise.

Identifier les rôles et responsabilités

Cette cartographie permet également d’identifier la position exacte de l’organisation dans l’écosystème de l’IA. Une entreprise peut être simple utilisatrice d’outils tiers dans certains cas, et déployeuse ou intégratrice dans d’autres. Or cette qualification n’est pas neutre. Elle détermine le niveau d’obligations, les diligences attendues, les vérifications à mener et les clauses à sécuriser.

Prioriser les risques

Elle permet enfin de hiérarchiser les priorités. Tous les usages ne présentent pas le même niveau de risque, de criticité ou d’impact. Une logique de gouvernance mature consiste précisément à distinguer les cas d’usage anodins, les usages sensibles et ceux qui exigent un encadrement renforcé ou une validation préalable. C’est souvent à ce moment que l’entreprise a besoin d’un regard extérieur capable d’articuler lecture juridique, compréhension des outils et mise en œuvre pragmatique.

 

Une gouvernance nécessairement transverse

L’IA est un sujet transversal et suppose une coordination entre plusieurs fonctions : direction générale, direction juridique, DPO, RSSI, DSI, achats, ressources humaines, métiers, et parfois communication ou RSE selon les usages concernés. Cette transversalité est un réel gage d’efficacité. L’IA n’est ni un simple outil technique, ni un sujet purement réglementaire. C’est un sujet d’entreprise, qui touche à la donnée, aux processus, aux responsabilités, aux actifs immatériels, à l’organisation du travail et à la relation de confiance avec les parties prenantes. Traiter l’IA comme un véritable sujet stratégique implique donc de définir des rôles, des circuits de validation, des seuils d’escalade, des responsabilités claires et, surtout, une méthode de décision.

 

Structurer la gouvernance IA : charte, contrats et formation

Une fois les principes posés, il convient de traduire la gouvernance en outils concrets et opérationnels.

La charte IA

Une fois les usages identifiés et les responsabilités clarifiées, encore faut-il structurer le cadre.

La charte IA constitue souvent une première brique utile. Mais elle ne doit pas être un simple document d’affichage. Pour être réellement opérante, elle doit préciser les usages autorisés et interdits, les catégories de données exclues, les exigences en matière de validation humaine, les règles de transparence, les principes de sécurité, les outils autorisés ou proscrits, ainsi que les obligations de vigilance attendues des collaborateurs.

Sa portée juridique doit en outre être appréciée à l’aune du droit social lorsqu’elle affecte les conditions de travail, crée des obligations nouvelles ou s’articule avec le pouvoir disciplinaire. Elle peut alors nécessiter une intégration adéquate dans le règlement intérieur, une mise à jour de la charte informatique et, selon les cas, la mise en œuvre des consultations requises, notamment du CSE.

Le volet contractuel

Le volet contractuel est tout aussi déterminant. Les entreprises doivent examiner avec attention les engagements offerts par les fournisseurs d’outils, notamment en matière de confidentialité, de sécurité, de localisation des données, de réutilisation des données d’entrée et de sortie, de responsabilité et de garanties de propriété intellectuelle.

Elles doivent également adapter leurs propres contrats afin d’encadrer les usages de l’IA dans leurs relations avec leurs clients, partenaires, prestataires ou utilisateurs finaux.

La formation et la sensibilisation

Enfin, aucune gouvernance IA ne peut fonctionner sans formation ni sensibilisation des collaborateurs aux risques juridiques, aux limites des outils et aux bons réflexes à adopter. Une politique bien rédigée mais mal comprise ne protège pas l’entreprise.

Sensibiliser les équipes, adapter les messages aux métiers et diffuser une culture commune de la maîtrise constitue donc un impératif aussi bien opérationnel que juridique.

 

De la conformité à la confiance

La gouvernance IA suppose de suivre les usages, de mettre à jour les règles internes, de documenter les décisions, de réévaluer les outils et d’ajuster la feuille de route au fil de l’évolution des pratiques et du cadre réglementaire. Il s’agit d’un cycle continu. Les entreprises les plus matures sur ce sujet sont celles qui savent identifier les usages à valeur ajoutée, mesurer les risques, mettre en place les garde-fous adaptés et démontrer qu’elles maîtrisent raisonnablement leurs choix. À ce titre, la gouvernance IA peut devenir un véritable avantage concurrentiel. Une entreprise capable de démontrer des pratiques responsables, structurées et transparentes en matière d’intelligence artificielle renforce sa crédibilité auprès de ses clients, de ses partenaires, de ses investisseurs et de ses collaborateurs. Pour les entreprises, la question est donc de savoir comment encadrer l’IA de manière proportionnée, opérationnelle et juridiquement sécurisée. C’est précisément à cette articulation entre innovation, gouvernance et maîtrise des risques qu’une démarche juridique bien construite doit répondre.

 

Checklist opérationnelle : par où commencer ?

Pour passer du constat à l’action, plusieurs chantiers peuvent être engagés :

• Cartographier les usages : identifier les outils d’IA déjà utilisés ou envisagés, les finalités poursuivies, les données manipulées, les équipes concernées et les environnements techniques mobilisés.
• Qualifier les rôles : déterminer la position exacte de l’entreprise dans la chaîne de valeur de l’IA — utilisatrice, déployeuse, intégratrice, distributrice ou fournisseuse — afin d’identifier les obligations applicables.
• Formaliser une charte IA : encadrer les usages autorisés et interdits, les catégories de données exclues, les règles de validation humaine, de traçabilité, de transparence et de sécurité.
• Procéder à une revue contractuelle : analyser les engagements proposés par les fournisseurs d’outils et adapter les contrats clients, prestataires ou partenaires pour intégrer les clauses spécifiques liées à l’IA.
• Articuler RGPD, RIA et propriété intellectuelle : éviter une approche en silos et construire un cadre cohérent entre protection des données, gouvernance réglementaire de l’IA et sécurisation des droits.
• Sensibiliser les équipes : former les collaborateurs aux bons usages, aux limites des outils, aux réflexes de sécurité et aux principaux risques juridiques et opérationnels.

 

À propos de l’auteur

Léa Puigmal est avocate au barreau de Paris, spécialisée en droit du numérique, des technologies et de l’innovation. Fondatrice de LPL Avocat, elle accompagne les entreprises à tous les stades de leur développement en leur apportant un soutien juridique et opérationnel sur les enjeux Tech, Data et IA.

Plusieurs textes dont la loi SREN, le Data Act et la directive NIS 2 imposent directement de nouvelles obligations aux prestataires SaaS, qui les contraignent à revoir certaines pratiques et leurs modèles de contrats.

Les services d’informatique en nuage (ou « cloud ») se sont imposés comme un outil majeur de la transformation numérique. Ainsi, près de la moitié des entreprises européennes ont acheté des services cloud en 2023, et 95% de ces acheteurs de services cloud ont souscrit au moins à un service SaaS (« Software as a Service »)¹.

Les législateurs français et européens cherchent non seulement à encadrer la sécurité de ces services et des données traitées, mais aussi à limiter les déséquilibres concurrentiels sur le marché du cloud. Des obligations ont ainsi récemment été imposées aux prestataires SaaS par plusieurs textes, qui les contraignent à revoir certaines pratiques et leurs modèles de contrats.

 

Les points clés à retenir

• Le Data Act et la loi SREN structurent les conditions de changement de fournisseur, en encadrant les frais associés et en introduisant des obligations d’interopérabilité et de portabilité des services cloud.
• Les prestataires SaaS doivent assurer une transparence accrue sur la localisation et la protection des données.
• La loi SREN introduit des exigences spécifiques en France, notamment en matière environnementale et de souveraineté.
• La directive NIS 2 durcit les obligations de cybersécurité (gestion des risques, notification d’incidents).
• Les manquements exposent à des sanctions financières significatives, en plus des exigences contractuelles sectorielles (ex. DORA).

 

1. Les obligations et contraintes visant à renforcer la concurrence et la souveraineté des données

Le règlement européen 2023/2854 du 13 décembre 2023 (le Règlement sur les Données ou « Data Act ») et la loi française n° 2024-449 du 21 mai 2024 visant à sécuriser et à réguler l’espace numérique (la « Loi SREN ») imposent de nouvelles règles respectivement aux « fournisseurs de services de traitement de données » et aux « fournisseurs de services d’informatique en nuage ». Curieusement, ces notions sont définies de façon identique, et le Data Act prévoit expressément que cette définition couvre les services SaaS².

À noter que les obligations issues de la loi SREN ne concernent que les prestataires cloud établis en France ou hors de l’UE (pour respecter le principe européen de libre circulation des services)³.

1.1 Les règles visant à favoriser la concurrence sur le marché du cloud

Le Data Act et la loi SREN cherchent notamment à favoriser la concurrence sur le marché cloud, brigué par quelques prestataires dominants (présents sur toutes les couches du marché du cloud, y compris la couche SaaS) et dont les pratiques peuvent rendre leurs clients captifs⁴.

Ces textes encadrent ainsi les frais de changement de fournisseur (y compris en cas de recours simultané à plusieurs prestataires), et notamment les frais de transfert de données. Le Data Act prévoit que les frais de changement de fournisseur ne peuvent dépasser les coûts directement liés au processus de changement jusqu’au 12 janvier 2027, puis interdit complètement ces frais à compter de cette date⁵. Pour sa part, la loi SREN prévoit que, jusqu’au 12 janvier 2027, la facturation de frais de changement de fournisseur devra respecter un montant maximal de tarification fixé par arrêté⁶.

[note de l’APP] L’Arcep a officiellement transmis au Gouvernement sa proposition de fixer le montant maximal à 0 €⁷ pour les frais de transfert de données, anticipant ainsi l’interdiction totale prévue par le Data Act au 12 janvier 2027.

De plus, tant le Data Act (à partir du 12 septembre 2025) que la loi SREN (entre sa promulgation et le 12 janvier 2027) impose des obligations d’interopérabilité et de portabilité des données, en particulier via la mise à disposition par les prestataires cloud d’interfaces dédiées. Il est prévu que des spécifications d’interopérabilité seront publiées respectivement via un acte délégué de la Commission Européenne et par l’Arcep en France⁸.

[note de l’APP] L’Arcep a publié le 25 septembre 2025 une recommandation officielle relative à l’interopérabilité et à la portabilité des services cloud⁹, précisant les modalités d’application de ces obligations pour les prestataires.

Les prestataires cloud doivent en outre fournir à leurs clients, y compris dans leurs contrats et à travers leurs sites Internet, des informations sur les frais de changement de fournisseur¹⁰. Le Data Act impose des obligations d’information complémentaires significatives, et notamment des clauses contractuelles sur le changement de fournisseur et l’interopérabilité¹¹. Des clauses types reprenant ces éléments seront élaborées au niveau européen mais ne seront pas obligatoires¹².

La loi SREN comprend en outre plusieurs interdictions additionnelles, visant également à limiter les déséquilibres concurrentiels¹³. Ainsi, les prestataires cloud ne peuvent établir d’avoirs ayant une durée indéterminée (des durées acceptables seront fixées par décret et ne pourront dans tous les cas dépasser un an) ou assortis d’une condition d’exclusivité. Il est également interdit aux prestataires cloud de subordonner la vente d’un produit ou service à la souscription à un service cloud lorsque cela constitue une pratique commerciale déloyale¹⁴.

1.2 Les règles relatives aux transferts et à la souveraineté des données

Le Data Act et la loi SREN (jusqu’au 12 janvier 2027 pour cette dernière), afin de permettre aux clients de prendre une décision éclairée quant au choix de leurs prestataires, imposent aux prestataires cloud de publier sur leur site internet les juridictions dans lesquelles les données des services cloud pourraient être traitées ainsi qu’une description des mesures prises pour empêcher l’accès par des autorités publiques hors de l’UE à des données personnelles en conflit avec le droit applicable. Un changement contractuel additionnel est requis à cet égard, puisque les prestataires doivent lister les URL concernées dans les contrats avec leurs clients¹⁵.

De plus, la loi SREN incorpore dans la loi française les exigences qui figuraient dans les circulaires relatives à la doctrine « cloud au centre »¹⁶. Elle prévoit ainsi que les administrations et opérateurs de l’Etat, lorsqu’ils utilisent un service cloud qui traite des données d’une sensibilité particulière et dont la violation est susceptible de porter atteinte à certains droits ou intérêts, doivent s’assurer que ce service respecte des critères de sécurité et protection des données notamment pour éviter tout accès par des autorités étrangères¹⁷. Un projet de décret, notifié à la Commission européenne le 24 janvier 2025, impose le recours à un prestataire qualifié par l’Anssi (ou ayant une certification européenne équivalente). Le référentiel de qualification applicable sera très vraisemblablement du référentiel « SecNumCloud » visé dans les circulaires.

1.3 Une spécificité française : la fourniture d’information environnementale

Un autre ajout dans la loi SREN par rapport au Data Act est à noter : les prestataires cloud seront tenus de publier des « informations sur l’empreinte environnementale de leurs services, notamment en matière d’empreinte carbone, de consommation d’eau et de consommation d’énergie ». Les délais et modalités d’application de cette obligation seront précisées par décret¹⁸.

 

2. Le renforcement des obligations de cybersécurité

La directive (UE) 2022/2555 du 14 décembre 2022 (la « directive NIS 2 ») accroît pour sa part les obligations de cybersécurité applicables aux prestataires SaaS par rapport à la directive « NIS 1 »¹⁹.

2.1 Champ d’application

La directive NIS 2 s’applique aux fournisseurs de services d’informatique en nuage (ces services comprenant entre autres « les logiciels services (SaaS) »)²⁰, essentiellement lorsqu’ils constituent des grandes ou des moyennes entreprises au sens du droit européen²¹. Ces entités seront, selon les règles prévues à l’article 3 de la directive, des entités « essentielles » ou « importantes ».

2.2 Obligations des prestataires SaaS au titre de la directive NIS 2

Les obligations des entités soumises à la directive NIS 2 doivent notamment être fixées dans les textes de transposition adoptées par les États membres. Bien que la transposition devait avoir lieu au plus tard le 17 octobre 2024²², l’adoption de la loi de transposition française est toujours attendue²³.

L’état d’avancement de la transposition en droit français

Le projet de loi de transposition a été voté au Sénat en mars 2025 (Rapport Sénat n° 393 (2024-2025) du 4 mars 2025) et a été examiné à l’Assemblée nationale en septembre 2025, avec une adoption attendue début 2026 (Ornisec, « Directive NIS 2 : vers une cybersécurité renforcée en Europe – Point de situation », juin 2025). En mai 2025, la Commission européenne a envoyé un avis motivé à la France pour défaut de notification de la transposition complète (Commission européenne, page de suivi de la transposition NIS 2 pour la France, mise à jour du 7 mai 2025), soulignant le retard pris par rapport à l’échéance du 17 octobre 2024.

Le mécanisme de guichet unique applicable aux fournisseurs de services numériques

La détermination de la loi de transposition applicable sera particulièrement importante pour les fournisseurs de services numériques, y compris les prestataires SaaS, pour lesquels la directive prévoit un mécanisme de « guichet unique ». Contrairement aux autres entités soumises à ce texte, qui peuvent relever de la compétence de plusieurs États membres²⁴, les fournisseurs de services numériques relèvent uniquement de la compétence de l’État membre dans lequel les fournisseurs ont leur établissement principal dans l’Union²⁵. La notion d’établissement principal a une signification particulière dans le cadre de la directive NIS 2, puisqu’elle est définie essentiellement en lien avec les mesures ou opérations en matière de cybersécurité²⁶.

L’obligation d’enregistrement auprès de l’autorité compétente

Les prestataires de services numériques seront notamment soumis à une obligation de déclaration auprès de l’État membre dans lequel se situe leur établissement principal. Bien que la directive prévoie que la première déclaration devait être effectuée au plus tard le 17 janvier 2025²⁷, les délais et modalités de déclaration seront en pratique fixées par les lois de transposition²⁸.

Les obligations européennes directement applicables : gestion des risques

Certaines obligations applicables aux prestataires SaaS sont pour leur part fixées au niveau européen (et non au niveau des lois de transposition). Ainsi, les mesures de gestion des risques en matière de cybersécurité devant être mises en œuvre par les fournisseurs de services numériques²⁹ sont définies dans le règlement d’exécution (UE) 2024/2690, qui est directement applicable dans tous les États membres de l’Union européenne depuis le 6 novembre 2024.

D’autres obligations devront être étudiées tant au niveau des textes européens que des lois de transposition : les prestataires cloud sont soumis à l’obligation de notification des incidents importants auprès de l’autorité compétente et le cas échéant des destinataires des services prévue à l’article 23 de la directive NIS 2 (telle qu’elle sera transposée par les États membres), étant précisé que le règlement d’exécution susmentionné définit les cas dans lesquels un incident relatif à un service cloud est considéré comme important.

 

Un nouvel environnement normatif structurant pour les prestataires SaaS

Les prestataires SaaS doivent mettre en œuvre les modifications techniques et contractuelles requises pour éviter des sanctions significatives (par exemple jusqu’à 3% du chiffre d’affaires mondial pour certains manquements à la loi SREN, jusqu’à 10 millions d’euros d’amende ou 2% du chiffre d’affaires mondial en cas de manquements des entités essentielles à certaines dispositions de NIS 2, etc.). Ces contraintes leur étant directement applicables sont bien sûr sans préjudice des obligations pouvant leur être imposées contractuellement par leurs clients en vertu de nouvelles règlementations sectorielles les concernant (par exemple Dora³⁰).

 

Notes

[1] Eurostat, « Cloud computing – statistics on the use by enterprises ». ︎

[2] Considérant 81 du Data Act. ︎

[3] Article 35 de la loi SREN. ︎

[4] Étude d’impact de la loi SREN. ︎

[5] Article 29 du Data Act. ︎

[6] Article 27 de la loi SREN. ︎

[7] Décision n° 2025-0340 du 20 février 2025 de l’Arcep. ︎

[8] Articles 30, 34 et 35 du Data Act, articles 28 et 29 de la loi SREN. ︎

[9] Recommandation de l’Arcep du 25 septembre 2025 relative à l’interopérabilité et à la portabilité des services d’informatique en nuage. ︎

[10] Article 27 de la loi SREN, articles 25, 29.4 et 29.6 du Data Act. ︎

[11] Articles 25 et 26 du Data Act. ︎

[12] Article 41 du Data Act ; voir aussi la FAQ de la Commission sur le Data Act. ︎

[13] Basées sur l’avis de l’Autorité de la concurrence du 29 juin 2023 dédié au marché cloud. ︎

[14] Nouvel article L. 442-12 du Code de commerce, créé par l’article 26 de la loi SREN. ︎

[15] Article 28 du Data Act et article 33 I de la loi SREN. ︎

[16] Circulaire n° 6282-SG du 5 juillet 2021 et circulaire n° 6404/SG du 31 mai 2023. ︎

[17] Article 31 de la loi SREN. ︎

[18] Article 33 II de la loi SREN. ︎

[19] Les règles prévues pour les « fournisseurs de services numériques » par le Règlement d’exécution 2018/151 étaient en particulier moins développées. ︎

[20] Annexe I section 8 et considérant 33. ︎

[21] Article 2.1 de la directive, qui fait référence à la recommandation 2003/361/CE du 3 mai 2003. Voir notamment les dispositions de la recommandation, ainsi que le considérant 16 de la directive, sur les entreprises partenaires et liées à prendre en compte pour le calcul des seuils. A noter également les articles 2.2 b) à f) ou 2.3 sur les autres entités pouvant être soumises à NIS 2. ︎

[22] Article 41. ︎

[23] La France n’est pas le seul pays concerné, par exemple le projet de loi de transposition n° 8364 étant également toujours en suspens au Luxembourg. ︎

[24] Article 26.1 et considérant 113. ︎

[25] Article 26.1 b). Voir également les règles pour les prestataires étrangers à l’article 26.3. ︎

[26] Article 26.2 et considérant 114. ︎

[27] Article 27.2. ︎

[28] Par exemple, la loi de transposition belge du 26 avril 2024 prévoyait une date limite d’enregistrement au 18 décembre 2024. ︎

[29] Article 21. ︎

[30] A noter toutefois que pour certains prestataires TIC critiques Dora leur sera applicable directement. ︎

Le SBOM (Software Bill of Materials) s’impose comme un outil de référence pour comprendre ce qui compose réellement un logiciel livré, déployé et maintenu. Là où l’on raisonnait historiquement en “produit” (une application, un service SaaS, un composant embarqué), l’industrialisation du développement a déplacé l’attention vers l’assemblage : dépendances open source, bibliothèques tierces, services externes, images conteneurisées, paquets système et dépendances transitives.

Concrètement, cela signifie qu’un logiciel est exposé non seulement à travers ce que l’on développe soi-même, mais aussi à travers tout ce que l’on y ajoute. Le SBOM donne une visibilité structurée sur cet assemblage, au service de trois objectifs : cybersécurité, conformité, maîtrise des actifs immatériels. Les textes européens récents n’imposent pas toujours “le SBOM” en tant que tel, mais renforcent les exigences de traçabilité et de gestion des risques qui en font un outil de premier plan.

 

Les points clés à retenir sur le SBOM

• Le SBOM est un inventaire structuré des composants intégrés dans un logiciel.
• Il facilite l’identification des vulnérabilités (ex. CVE) et la priorisation des correctifs.
• Il soutient la gestion des risques liés à la chaîne d’approvisionnement, notamment au regard de NIS 2.
• Il contribue à la documentation technique et à la gestion des vulnérabilités attendues par le Cyber Resilience Act.
• Il sécurise les enjeux de licences open source, de due diligence et d’engagements contractuels.
• Sa valeur augmente lorsqu’il est intégré à une stratégie de preuve (dépôt, horodatage) et, le cas échéant, de continuité (entiercement).

 

Le SBOM : définition, périmètre et enjeux techniques

Le SBOM s’inscrit dans une logique de transparence et de maîtrise de la chaîne d’approvisionnement logicielle. Pour en comprendre la portée, il convient d’en préciser la définition, les standards applicables et les implications techniques concrètes.

Définition opérationnelle du SBOM

Un SBOM peut être défini comme un enregistrement formalisé des composants utilisés pour construire un logiciel et des relations de dépendance associées. Cette définition est notamment consacrée dans les travaux américains liés à l’Executive Order 14028 et dans la doctrine de référence portée par NIST et NTIA.

Concrètement, un SBOM liste des éléments identifiables : nom du paquet, éditeur/projet, version, empreintes, licences déclarées, identifiants standards et parfois informations de provenance. Il peut couvrir plusieurs couches : dépendances applicatives (ex. npm, Maven, PyPI), dépendances système (paquets OS), et composants de déploiement (images, conteneurs). Ce degré de précision ne relève pas d’un simple formalisme documentaire : elle conditionne la capacité à répondre à une alerte de sécurité, à documenter une conformité, ou à démontrer une maîtrise de sa chaîne logicielle.

Formats et standards : SPDX, CycloneDX, et ce qu’ils changent

Le SBOM n’est pas un fichier “maison” : l’intérêt est précisément de s’appuyer sur des standards interprétables par des outils et par des tiers. Les formats les plus fréquents sont SPDX et CycloneDX, auxquels s’ajoutent des variantes ou profils selon les secteurs et les outils d’analyse.

Un choix de format n’est pas neutre. Il conditionne :

• Le niveau de détail sur les dépendances transitives,
• La capacité à exprimer des métadonnées de sécurité (hash, provenance),
• L’interopérabilité avec les outils de scan de vulnérabilités,
• La facilité d’échange avec un client, un auditeur ou une autorité.

Dans une logique de gouvernance, l’enjeu consiste moins à “produire un SBOM” qu’à produire un SBOM exploitable, cohérent avec le cycle de vie du logiciel et intégrable dans les processus de sécurité et de conformité.

Ce que le SBOM révèle vraiment : dépendances transitives, héritage et dette technique

La valeur d’un SBOM tient largement à sa capacité à exposer les dépendances transitives : composants intégrés indirectement, parfois inconnus des équipes produit, mais présents dans l’artefact livré. C’est souvent à ce niveau que se nichent les risques : versions obsolètes, bibliothèques non maintenues, modules qui tirent eux-mêmes des dépendances vulnérables.

Le SBOM permet également d’objectiver une dette de dépendances : accumulation de versions anciennes, multiplication de bibliothèques redondantes, ou dépendance forte à un composant unique. Pour une direction technique, cela nourrit une trajectoire de maintenance. Pour une direction juridique ou conformité, cela permet d’identifier les dépendances associées à des licences à obligations de réciprocité, ou de vérifier que les obligations de notices sont respectées. Le SBOM devient ainsi un point d’entrée commun entre RSSI, CTO, DSI, juristes et acheteurs.

 

SBOM et exigences réglementaires européennes : vers une obligation indirecte

Il est utile de clarifier un point : le droit de l’Union ne dit pas toujours “vous devez produire un SBOM”. En revanche, plusieurs textes structurants imposent des obligations de gestion des risques, de maîtrise de la chaîne d’approvisionnement, de documentation et de traitement des vulnérabilités. Dans ce cadre, le SBOM s’insère comme un mécanisme de preuve et d’exécution des politiques internes.

Cette approche est cohérente avec la logique européenne : fixer des objectifs et des exigences (gérer le risque, réduire l’exposition, tracer les composants, traiter les vulnérabilités), tout en laissant les organisations choisir les outils et démarches pour y parvenir. Le SBOM n’est donc pas une case à cocher ; il s’analyse comme un instrument de gouvernance aligné sur des obligations déjà présentes, dont l’intensité varie selon le secteur, le produit et le niveau de risque.

Directive NIS 2 : gestion des risques et chaîne d’approvisionnement

La directive NIS 2 (directive (UE) 2022/2555) renforce les mesures de gestion des risques de cybersécurité attendues des entités concernées. Elle vise notamment la gestion des risques liés à la chaîne d’approvisionnement et la sécurisation des systèmes au travers d’une approche par les risques.

Dans une organisation soumise à NIS 2 (directement ou via exigences contractuelles), la question devient : comment démontrer que l’on connaît ses composants, que l’on sait repérer une exposition, et que l’on sait remédier ?

Le SBOM apporte une réponse méthodologique :

• cartographie,
• corrélation avec les vulnérabilités,
• priorisation,
• traçabilité de la remédiation.

Les guides de mise en œuvre et l’écosystème de conformité autour de NIS 2 soulignent l’importance de mesures opérationnelles et vérifiables, ce que permet un SBOM maintenu dans le temps.

Cyber Resilience Act : documentation technique et gestion des vulnérabilités

Le Cyber Resilience Act (règlement (UE) 2024/2847) établit des exigences de cybersécurité pour les produits comportant des éléments numériques, avec une attention particulière portée à la sécurité dès la conception et à la gestion des vulnérabilités sur la durée de support.

Dans cette logique, le SBOM constitue un support naturel de documentation : il décrit les composants intégrés et facilite l’analyse d’exposition lorsqu’une vulnérabilité est divulguée. Il contribue également à la gestion des mises à jour et à la transparence attendue par les utilisateurs et les clients professionnels, notamment lorsque des périodes de support et des correctifs doivent être organisés et documentés. L’enjeu n’est pas seulement technique : c’est une question de responsabilité produit, de capacité à gérer les alertes et à démontrer que l’on maîtrise son assemblage logiciel.

DORA : supervision des prestataires TIC et auditabilité

Le règlement DORA (règlement (UE) 2022/2554) organise la résilience opérationnelle numérique du secteur financier, notamment au travers d’exigences encadrant la relation avec les prestataires TIC et les dispositions contractuelles.

Même si DORA ne prescrit pas explicitement “un SBOM”, la dynamique de conformité pousse à renforcer la visibilité sur les dépendances et sur les composants qui soutiennent des fonctions sensibles. Pour un prestataire TIC travaillant avec des entités financières, fournir un SBOM (ou un équivalent structuré) devient un signal de maturité : capacité à documenter l’architecture logicielle, à qualifier des dépendances, à accélérer une analyse en cas d’incident, et à soutenir des démarches d’auditabilité. Dans les négociations contractuelles, cette transparence peut être déterminante pour démontrer l’alignement opérationnel entre engagements de sécurité et réalité technique.

 

SBOM et propriété intellectuelle : un outil de maîtrise des actifs logiciels

Au-delà de la cybersécurité, le SBOM constitue un outil de pilotage des droits et actifs logiciels : il distingue les développements internes des composants tiers et open source, et permet d’identifier les obligations juridiques associées (licences, redistribution, documentation).

Gouverner les licences open source : de la conformité à la sécurisation contractuelle

L’intégration de composants open source est devenue une norme. Le risque ne réside pas dans l’open source en soi, mais dans l’absence de gouvernance : méconnaissance des licences, dépendances introduites sans validation, obligations de notices non respectées, ou incompatibilités entre licences et modèle de distribution.

Le SBOM permet d’identifier et d’agréger les informations de licence par composant. Il soutient une politique interne : validation des dépendances, règles d’acceptation (ex. interdiction de certaines licences dans certains produits), gestion des obligations de redistribution, et documentation destinée aux clients. Dans le cadre d’appels d’offres ou de contrats B2B, la capacité à produire un SBOM et une synthèse de conformité open source permet également de limiter les frictions : la discussion ne porte plus sur des déclarations générales, mais sur une cartographie vérifiable.

Due diligence technologique : de l’inventaire à l’évaluation du risque

Lors d’une due diligence (acquisition, partenariat structurant, levée de fonds, transfert d’actifs), le SBOM apporte un niveau d’objectivation rarement atteint par une simple revue documentaire. Il aide à répondre à des questions centrales :

• dépendance à quelques briques tierces,
• présence de composants non maintenus,
• exposition potentielle à des vulnérabilités connues,
• alignement des licences avec la stratégie de commercialisation.

Il permet aussi de mieux qualifier la valeur d’un actif logiciel : un produit dont la chaîne de dépendances est maîtrisée, mise à jour, et documentée est plus facile à maintenir, à intégrer et à auditer. À l’inverse, l’absence de visibilité sur les composants introduit une incertitude technique et juridique qui se traduit souvent en renégociations, garanties renforcées, ou mécanismes d’ajustement de prix.

Dans le cadre de ces audits, certains acteurs spécialisés en due diligence technologique, comme notre partenaire Vaultinum, proposent des dispositifs permettant de générer un SBOM, accompagné d’un rapport explicatif au format PDF destiné aux parties prenantes non techniques (direction générale, investisseurs, juristes, conseils).

SBOM, preuve et titularité : articuler traçabilité technique et stratégie probatoire

Le SBOM distingue ce qui relève des composants internes et ce qui relève de composants externes. Cette distinction est utile pour piloter la titularité, la réutilisation et la stratégie de protection. Toutefois, le SBOM ne remplace pas une stratégie probatoire : il décrit, mais ne confère pas une preuve d’antériorité ou de paternité sur les développements internes.

Dans une logique de protection des actifs numériques, il est pertinent d’articuler SBOM et dispositifs probatoires : dépôt et horodatage de versions significatives, dépôts de documentation technique associée, et conservation des éléments permettant de démontrer une chronologie de développement. C’est typiquement dans ce type d’articulation qu’un tiers de confiance, comme l’Agence pour la Protection des Programmes, intervient : sécuriser la preuve des actifs logiciels (code source, documentation, versions) et soutenir la gouvernance interne lors d’un audit, d’un contentieux ou d’une négociation.

 

Contrats, achats, et exigences clients : le SBOM comme clause de transparence

À mesure que les exigences de cybersécurité et de conformité s’intensifient dans les entreprises, le SBOM tend à quitter la seule sphère technique pour devenir un objet contractuel.

Le SBOM comme exigence client dans les contrats B2B

Côté clients, le SBOM peut être demandé pour : vérifier l’absence de composants interdits, qualifier les risques liés à la software supply chain, ou organiser des procédures de notification en cas de vulnérabilité affectant un composant intégré.

Dans certains secteurs très surveillés et soumis à une réglementation contraignante (finance, santé, défense, infrastructures critiques), le SBOM permet d’objectiver la composition logicielle du produit livré et d’encadrer les obligations de transparence.

Encadrer clairement l’usage du SBOM dans le contrat

Côté fournisseurs, le SBOM doit faire l’objet d’un encadrement précis : déterminer quels livrables sont concernés, à quelle fréquence il est mis à jour, quel périmètre il couvre (produit, module, image conteneurisée) et dans quelles conditions il peut être utilisé ou communiqué (confidentialité, non-divulgation, responsabilité).

Sans cet encadrement, le SBOM peut être perçu à tort comme une garantie d’absence de vulnérabilités. Or, il s’agit d’un inventaire destiné à faciliter la gestion des risques, non d’une assurance contre ceux-ci.

 

SBOM et offre APP : un inventaire technique et un rapport explicatif

Au-delà de la production d’un inventaire technique, la valeur du SBOM réside dans sa capacité à être compris, exploité et intégré dans une stratégie de gouvernance des actifs logiciels. C’est précisément sur ce point que se distingue l’approche de l’APP.

Une génération de SBOM intégrée aux dépôts

L’Agence pour la Protection des Programmes propose désormais, en option dans le cadre de ses dépôts (standards, vérifiés et contrôlés), une prestation de génération de SBOM.

Cette offre permet aux éditeurs de logiciels et à leurs clients d’obtenir :

• un fichier SBOM au format JSON, conforme aux standards du marché ;
• un rapport complémentaire au format PDF pour rendre le livrable exploitable et compréhensible pour tous.

Le SBOM ainsi généré s’inscrit dans une logique de sécurisation et de réassurance : il accompagne le dépôt horodaté du code source et contribue à renforcer la valorisation de l’actif logiciel.

Un rapport PDF explicatif à destination des parties prenantes non techniques

La principale valeur ajoutée de l’offre APP réside dans la production d’un rapport explicatif au format PDF, conçu pour être lisible par des interlocuteurs non techniques (direction générale, investisseurs, juristes, partenaires commerciaux).

Contrairement à certaines solutions concurrentes, parfois gratuites mais compréhensibles uniquement par les équipes IT, l’APP fournit un document synthétique présentant :

• Les composants logiciels utilisés,
• Les licences associées,
• Les CVE (failles de vulnérabilité).

Ce document permet au client d’obtenir une vision claire et sécurisée de la composition de son code, et peut servir à faire valoir la qualité de l’actif auprès de tiers clients ou partenaires.

Modalités pratiques et transmission sécurisée

Les deux livrables — SBOM en JSON et rapport explicatif en PDF — peuvent être transmis par voie électronique. Leur poids, après compression, demeure inférieur à 1 Mo, ce qui facilite leur envoi sécurisé par courriel dans le cadre d’un audit, d’une négociation contractuelle ou d’une opération stratégique.

L’offre SBOM s’inscrit en complément des dispositifs historiques de l’APP :

• dépôt probatoire horodaté des versions de code et de documentation ;
• entiercement logiciel, notamment en contexte B2B ou SaaS, pour organiser la continuité d’activité si le fournisseur n’est plus en mesure d’assurer la maintenance ou l’accès, en cohérence avec les engagements contractuels.

Le SBOM ne constitue pas en soi un mécanisme probatoire. Il complète un dispositif global de protection, de traçabilité et de valorisation des actifs logiciels.

Pour toute information complémentaire sur l’option SBOM intégrée aux dépôts vérifiés et contrôlés, contactez les équipes de l’APP afin d’étudier votre situation et vos besoins spécifiques.

La bonne gestion des demandes d’exercice du droit d’accès aux données personnelles constitue une obligation essentielle pour toute entité soumise au RGPD et à la loi Informatique et Libertés. Ces entités, qu’elles soient publiques et privées et quelle que soit leur taille (entreprise, ministère, administration, association, etc.) doivent répondre efficacement et dans les délais aux demandes des personnes concernées par le traitement de leurs données à caractère personnel.

Face à l’augmentation des contrôles de la CNIL et des contentieux judiciaires sur ce sujet, il est crucial de comprendre les spécificités du droit d’accès, d’anticiper les difficultés pratiques et de mettre en place des procédures adaptées pour répondre aux demandes dans le respect de la réglementation.

Pourtant, certains aspects de la réglementation soulèvent dans la pratique de nombreuses questions pratiques et juridiques, tant sur le périmètre des informations à communiquer que sur les modalités de réponse et les limites à respecter. Cette FAQ vise à accompagner concrètement les professionnels dans la gestion conforme et sécurisée de ces droits, pour vous aider à sécuriser les pratiques et à limiter l’exposition au risque de sanction.

 

Périmètre du DSAR

1. En cas de demande d’accès aux emails, que doit-on communiquer ?

La question se pose souvent car en principe, le droit d’accès porte sur les données et non sur un document. Or, la Cour de cassation a pu préciser que le contenu du courriel est considéré comme une donnée personnelle dès lors qu’il permet d’identifier, directement ou indirectement, un individu (Cass. Soc., 18 juin 2025, n° 23-19.022, P). Il peut donc être important de le communiquer.

Dans le cas d’une demande exercée par un collaborateur, il peut être nécessaire de communiquer les courriels dans lesquels il est mentionné, mais dont il n’est ni l’émetteur ni le destinataire.  Le travail de collecte peut être fastidieux et l’employeur doit trouver un équilibre entre satisfaire le droit d’accès du salarié et respecter les droits et libertés des autres salariés, notamment le secret des correspondances. Pour cela, la CNIL recommande de procéder en deux temps :

1. S’assurer que les moyens à mettre en œuvre pour identifier les courriels demandés n’entraînent pas d’atteinte disproportionnée aux droits des salariés de l’organisme. Lorsque l’identification des courriels suppose la mise en œuvre de moyens particulièrement intrusifs (ex. scan de l’ensemble des messageries des salariés), le demandeur est invité à préciser sa demande. Si ce dernier s’y oppose, l’employeur devra répondre au droit d’accès pour les données contenues dans des courriels ne nécessitant pas de tels moyens intrusifs.

Si le demandeur précise sa demande et que cela permet d’identifier les courriels demandés sans atteinte disproportionnée au secret de la correspondance, il faut procéder à la deuxième étape.

2. Étudier le contenu des courriels et l’éventuelle atteinte aux droits des tiers du fait de leur communication, au regard du secret de la correspondance et de la vie privée de l’émetteur et des destinataires. L’analyse est menée au cas par cas, selon la nature des informations (ex. enquête disciplinaire, etc.).

La jurisprudence récente tend à durcir les obligations incombant à l’employeur, ce dernier ne pouvant rejeter en bloc une demande sans justifier des motifs de son refus, sans analyser les demandes au cas par cas. De son côté, les tribunaux opèrent un contrôle de proportionnalité sur le terrain du droit de la preuve et peuvent enjoindre les entreprises à communiquer une partie des documents nécessaire au litige en occultant les éléments sensibles.

 

2. Le droit d’accès porte-il également sur les métadonnées associées aux données à caractère personnel ?

La CNIL considère que, lorsqu’une personne concernée souhaite exercer son droit d’accès à des courriels, le responsable du traitement doit fournir tant les métadonnées (horodatage, destinataires, etc.) que les données personnelles contenues dans les courriels.

Dans cette hypothèse, le plus aisé est d’envoyer une copie des courriels. L’envoi d’un tableau contenant les métadonnées et les données personnelles contenues dans les différents courriels est également une solution.

 

3. Lorsqu’un salarié de plus de 20 ans d’ancienneté au sein d’une société demande une copie de ses emails, cela représente plusieurs millions de documents. Traiter sa demande est techniquement irréalisable… Comment faire ?

Si la demande est trop large ou imprécise, notamment lorsque le responsable du traitement traite une grande quantité de données sur la personne concernée, il peut être demandé des précisions afin d’y répondre efficacement. Il est alors recommandé demander à la personne de préciser sur quelles données ou quelles opérations de traitement sa demande porte.

Ainsi, dans le cas d’un salarié qui dispose d’une longue ancienneté, il est possible de demander de préciser la période, les mots-clés, ou les types de documents dont la copie est sollicitée.

La demande doit coïncider avec la durée de conservation des données, à savoir tant les durées de conservation qui résulterait d’obligations légales, que celles mises en place par la société. En effet, le responsable du traitement n’est pas tenu de fournir des courriels ou documents qui ne sont plus conservés conformément à sa politique de conservation ou aux obligations légales applicables. Il est donc recommandé d’informer le salarié de la période de conservation des courriels et de préciser que seuls les documents encore disponibles dans les systèmes de l’entreprise pourront être communiqués.

 

4.Hormis les emails, doit on communiquer tous les documents que nous détenons sur la personne, notamment les documents dans lesquels on peut retrouver les données personnelles de la personne (contrat de travail, notes internes, etc.) ?

Oui, tous les documents contenant des données personnelles concernant la personne doivent être communiqués, y compris son contrat de travail et les éventuels avenants, des notes internes le concernant, ses évaluations, ses emails, etc. dans le respect des limitations exposées par le RGPD. À ce titre, il convient de veiller à ne pas porter atteinte aux droits et libertés des tiers, tels que le secret des affaires, la vie privée d’autres salariés, ou un droit de propriété intellectuelle (par exemple le droit d’auteur, lorsqu’il protège le logiciel) et de respecter les exceptions légales applicables (demande est infondée ou excessive).

Avant toute communication, il est recommandé d’analyser chaque document pour occulter, si nécessaire, les informations susceptibles de porter atteinte aux droits d’autrui.

 

 

La qualité de l’information

5. Peut-on, en réponse à une demande d’information sur les données personnelles, se limiter à préciser la finalité principale et orienter la personne vers la politique de confidentialité pour le reste ?

Le RGPD pose un principe selon lequel plusieurs catégories d’informations sur les modalités de traitement des données personnelles sont à fournir à la personne concernée qui en fait la demande, notamment les finalités du traitement, les catégories de données concernées, les destinataires, la durée de conservation, les droits de la personne, outre le droit de réclamation auprès d’une autorité de contrôle, la source des données (si elles n’ont pas été collectées auprès de la personne concernée), et l’existence d’une prise de décision automatisée le cas échéant.

Il est possible de renvoyer à la politique de confidentialité pour fournir ces informations, à condition que celle-ci soit suffisamment détaillée et couvre l’ensemble des éléments requis. Si la politique de confidentialité n’est pas assez précise ou exhaustive, il convient de compléter la réponse pour garantir la conformité. Le Comité européen de la protection des données (CEPD) recommande d’adapter le contenu et le niveau de détail de la réponse en fonction de la demande formulée par la personne concernée.

 

6. Si le destinataire des données personnelles est un ou plusieurs sous-traitants, faut-il donner le nom et coordonnées de tous ces prestataires ?

L’article 15 du RGPD relatif au droit d’accès de la personne concernée prévoit que cette dernière doit être informée sur « les destinataires ou catégories de destinataires auxquels les données ont été ou seront communiquées ». Le RGPD n’exige pas expressément que les noms et coordonnées de tous les sous-traitants soient communiqués à la personne concernée par le traitement de ses données. Toutefois, le guide européen en la matière prévoit que, en application du principe d’équité, il convient de fournir les informations « les plus significatives sur les destinataires », ce qui comprend de « désigner nommément les destinataires afin que les personnes puissent savoir exactement qui détient leurs données personnelles » (G29, Lignes directrices sur la transparence au sens du règlement (UE) 2016/679, 2018).

Si le responsable du traitement choisit de se borner à communiquer les catégories de destinataires, les informations fournies doivent être les plus spécifiques possible sur le type de destinataire, notamment les activités de traitement concernées, le secteur et sous-secteur du destinataire, ainsi que son emplacement.

Si le destinataire est situé dans un pays tiers à l’Union européenne, il faut également informer la personne sur le pays tiers concerné, les garanties pertinentes prises pour garantir la protection des données personnelles, telle qu’une décision d’adéquation, ainsi que les moyens d’obtenir une copie de ces informations ou de connaître l’endroit où elles ont été mises à disposition.

 

 

Délai de réponse

7. Dans quels cas le délai d’un mois peut être augmenté jusqu’à 2 mois ?

Une demande doit être traitée « dans les meilleurs délais et, en tout état de cause, dans un délai d’un mois à compter de la réception de la demande ». Ce délai peut être prolongé de deux mois au maximum compte tenu de la complexité et du nombre de demandes, à condition que la personne concernée ait été informée des raisons de ce retard dans un délai d’un mois à compter de la réception de la demande.

Cette dérogation ne doit pas être utilisée de manière excessive.  Il faut apprécier au cas par cas les demandes susceptibles d’être considéré comme complexes. Les facteurs pertinents sont notamment la quantité de données traitées par l’organisme, la manière dont elles sont stockées (par exemple des données difficiles à récupérer, car traitées par différentes unités de l’organisme), la nécessité d’occulter des informations (par exemple des informations concernant des tiers ou qui constituent des secrets d’affaires), ou encore lorsque des travaux supplémentaires sont nécessaires pour rendre les informations intelligibles.

Le simple fait qu’une demande nécessite un effort important de traitement ne la rend pas « complexe » au sens du RGPD. De même, le fait qu’une grande entreprise reçoive un grand nombre de demandes ne justifie pas automatiquement une prolongation. Toutefois, si un grand nombre de demandes sont soudainement reçues (par exemple société visée par un « bad buzz »), cela peut constituer une raison légitime de prolonger le délai.

 

Vérification d’identité de la personne

8. A réception de demandes d’accès par email, nous demandons souvent une pièce d’identité pour confirmer l’identité, en précisant la raison pour laquelle ce justificatif est demandé. Généralement notre mail reste sans réponse. Que faire dans ce cas ?

En cas de doute raisonnable et sans justificatif d’identité, il n’est pas recommandé de répondre à la demande. En effet, communiquer des données personnelles à un tiers non autorisé risquerait de causer une violation de données personnelles susceptible d’engager la responsabilité de l’organisme.

Dès lors, sans réponse à la demande de justificatif d’identité, et sous réserve qu’un tel justificatif soit requis pour traiter la demande, cette dernière peut être considérée comme non recevable et le traitement suspendu. Il est recommandé de conserver la preuve de la demande de justificatif restée sans retour.

 

9. Pour un mineur, la demande de droit d’accès doit-elle être faite par les deux parents ou un seul suffit ?

Un seul parent titulaire de l’autorité parentale peut exercer le droit d’accès au nom du mineur. Il n’est pas nécessaire que les deux parents participent à la demande.

Cela étant dit, la CNIL considère que les mineurs peuvent exercer directement leurs droits sur leurs données personnelles lorsque cette démarche peut être regardée comme un « acte courant », notamment si elle correspond à l’intérêt supérieur de l’enfant. En ce sens, la CNIL estime que les mineurs doivent pouvoir exercer directement les droits relatifs à leurs données personnelles sur les réseaux sociaux, les plateformes de jeux et de partage de vidéos.

 

Modalités de réponse

10. En réponse à une demande d’accès, quels formats et moyens sont autorisés pour une transmission sécurisée des données ? Peut-on utiliser un canal de communication différent de celui employé par le demandeur ?

Dans la mesure du possible, le responsable du traitement doit permettre un accès à distance aux données personnelles idéalement via une fonctionnalité de téléchargement dans un format électronique courant et lisible (fichier PDF, XLX, etc.). Le format choisi doit garantir l’intelligibilité et l’accessibilité des informations.

En l’absence d’accès autonome, la transmission peut être électronique (avec des mesures de sécurité appropriées telles que cryptage ou mot de passe) ou non (par exemple un courrier recommandé, remis contre signature). L’envoi d’une clé USB par courrier recommandée est également possible.

Il est recommandé de répondre par le même canal de communication que celui utilisé par la personne mais l’utilisation d’un autre canal n’est pas contraire au RGPD.  Enfin, il est conseillé de confirmer par écrit la réception de la demande et d’indiquer le délai de traitement.

 

 

Traçabilité

11. Combien de temps doit-on garder copie des demandes traitées, notamment pour démontrer la conformité en cas de contrôle de la CNIL ?

La Loi Informatiques et Libertés et le RGPD ne prévoient pas de durée de conservation à cette fin. Pour ménager la capacité à démontrer le respect du RGPD, il est recommandé de conserver une trace de la gestion des demandes d’accès pendant une durée de cinq ans suivant la date de la réponse ou le dernier événement suivant celle-ci, le cas échéant.

 

 

Limites au DSAR

12. Quelles sont les limites du droit d’accès ? Quels sont les scénarios les plus courants ?

Les principales limites au droit d’accès tiennent à la possibilité de refuser de répondre aux demandes manifestement abusives ou excessive (demandes trop nombreuses, répétitives à des intervalles rapprochés, ou systématiques). Néanmoins, le responsable du traitement doit motiver sa décision et informer le demandeur des recours possibles.

Attention, le fait que la demande ne soit pas motivée (absence de justification) ne permet nullement de refuser d’y répondre.

Ainsi, une demande de droit d’accès formulée par un ancien salarié ayant engagé un contentieux prud’homal et qui porte sur la communication des motifs de son licenciement disciplinaire ne peut pas, en soi, être considéré comme abusif ou sans objet. À cet égard, la CNIL considère que les valeurs de classement annuel ou de potentiel de carrière sont communicables lorsqu’elles ont servi à prendre une décision concernant le salarié. L’employeur n’est pas tenu de les communiquer lorsqu’elles sont encore prévisionnelles, au jour de la demande.

Par ailleurs, le droit d’accès ne doit pas porter atteinte aux droits des tiers (secret des affaires, propriété intellectuelle, droits des tiers au respect de leur vie privée, sécurité publique, etc.). Par exemple, un salarié ne peut pas accéder aux données d’un autre salarié lorsqu’il existe un risque qu’une telle communication porte atteinte à sa vie privée ou au secret de ses correspondances.

Enfin, si aucune donnée n’est détenue sur la personne, le responsable doit tout de même répondre dans un délai d’un mois pour en informer le demandeur.

 

 

Risque de sanction

13. Concernant les contrôles CNIL, avez-vous des références de sanction du non-respect à une demande d’accès ?

La CNIL contrôle l’effectivité du respect du droit d’accès et rend régulièrement des décisions de sanction à ce sujet. En 2025, la CNIL a rendu publiques cinq décisions comportant des sanctions prononcées pour ce motif à l’encontre d’organismes de divers secteurs (e-commerce, immobilier, bancaire, santé, etc.). L’une des amendes prononcées notamment manquement pour non-respect du droit d’accès, s’élève à 150 millions d’euros (Délibération SAN-2025-005 du 1 septembre 2025).

 

A propos des auteures

Elisabeth Marrache et Gabrielle Pierre-Lenfant sont avocates au barreau de Paris et respectivement associée et collaboratrice du cabinet Addleshaw Goddard. Elles possèdent une expertise en propriété intellectuelle, nouvelles technologies et données personnelles.

Le modèle SaaS est devenu un standard dans l’édition de logiciels, offrant flexibilité, accessibilité et mises à jour automatiques qui simplifient la maintenance.

Largement plébiscité, et en croissance continue depuis plusieurs années (1), le format SaaS présente pour autant les mêmes risques qu’un logiciel “on premise” en cas de défaillance du fournisseur.

Ceci soulève donc la question suivante : comment garantir la continuité d’accès au logiciel et aux données en cas de défaillance du fournisseur SaaS ?

Cet article explique le fonctionnement du SaaS Escrow, ses avantages pour les les éditeurs de logiciel et leurs bénéficiaires, et les différences avec un contrat d’entiercement logiciel classique.

 

Les 5 points clés à retenir

• Le SaaS Escrow est un dispositif contractuel adapté aux spécificités des logiciels cloud, distinct du software escrow classique
• Il vise à garantir la continuité d’accès au service et aux données en cas de défaillance du fournisseur SaaS
• Le périmètre de l’entiercement SaaS couvre non seulement le code source, mais aussi les accès techniques, la documentation et les éléments nécessaires à l’exploitation du service
• Le SaaS Escrow s’inscrit en complément des clauses de réversibilité des données, afin de permettre la restitution des données dans un format exploitable
• Le rôle du tiers de confiance est central pour assurer la sécurité, la confidentialité et l’encadrement contractuel des conditions d’accès

 

Software escrow vs SaaS escrow, quelles différences ?

Avant d’aborder les bénéfices et enjeux du SaaS, il est utile de comprendre la distinction entre le software escrow classique et le SaaS Escrow.

Définition du software escrow (entiercement logiciel)

Ces deux dispositifs poursuivent un objectif comparable, qui est de garantir l’accès à des actifs logiciels en cas de défaillance du fournisseur, mais ils s’inscrivent dans des contextes techniques et contractuels différents.

Le software escrow repose sur un accord tripartite par lequel un éditeur de logiciel dépose auprès d’un tiers de confiance une copie du code source et, le cas échéant, de la documentation nécessaire à l’exploitation ou à la maintenance d’un logiciel installé sur l’infrastructure du client, généralement dans un environnement dit on premise. En cas de survenance d’événements définis au contrat, tels qu’une cessation d’activité ou une incapacité durable du fournisseur à assurer la maintenance, le bénéficiaire peut accéder au code source afin d’organiser la poursuite de l’exploitation du logiciel ou une transition vers un autre prestataire.

Définition du SaaS Escrow (entiercement SaaS)

Le SaaS Escrow applique cette logique d’entiercement à des solutions hébergées dans le cloud. Dans ce cadre, la continuité du service ne dépend pas uniquement du code source, mais également de l’environnement d’exécution, des configurations d’infrastructure, des accès techniques et, dans certains cas, des données hébergées.

Le SaaS Escrow repose sur un accord contractuel entre trois parties : le fournisseur du logiciel SaaS, le client utilisateur et un tiers de confiance, appelé agent d’entiercement ou tiers séquestre. Ce dernier conserve les éléments essentiels du logiciel et des données et intervient uniquement si certaines situations prédéfinies au contrat surviennent, comme une insolvabilité, une faillite ou une rupture contractuelle du fournisseur.

Le périmètre d’un SaaS Escrow est plus large que celui d’un software escrow classique. Il intègre des éléments permettant soit la continuité temporaire du service, soit la récupération et la réversibilité des données lorsque le prestataire n’est plus en mesure d’assurer le service. Cette différence tient à la nature même du modèle SaaS, fondé sur un service cloud évolutif, reposant sur des mises à jour continues, des dépendances d’infrastructure et des processus opérationnels spécifiques.

Réversibilité des données : un complément indispensable au SaaS Escrow

Pour les solutions SaaS, le contrat d’entiercement doit être complété par une clause de réversibilité des données, encore trop souvent absente des contrats. Si l’escrow agreement et la clause d’accès permettent au bénéficiaire d’accéder aux éléments déposés en cas de défaillance du fournisseur, ils ne garantissent pas systématiquement la restitution de données à jour.

En pratique, tous les fournisseurs SaaS ne procèdent pas à des dépôts quotidiens des éléments couverts par l’entiercement. Lorsque les données évoluent de manière fréquente, cette situation peut empêcher l’utilisateur de récupérer des informations récentes, pourtant essentielles à la continuité de son activité.

La clause de réversibilité vise précisément à encadrer cette restitution. Elle prévoit l’engagement du fournisseur à restituer au client l’ensemble de ses données dans un format exploitable, par exemple sous forme de fichiers de type Excel ou équivalent, dans un délai déterminé. Les modalités financières de cette restitution, souvent réalisées aux frais du bénéficiaire, dépendent toutefois des conditions négociées entre les parties lors de la conclusion du contrat.

 

Bénéfices et enjeux liés au SaaS

Avant de mettre en place un contrat de SaaS Escrow, il est utile de comprendre les principaux bénéficies et enjeux associés au modèle SaaS, tant pour les utilisateurs que pour les éditeurs.

Bénéfices pour les utilisateurs de logiciels cloud

Les solutions SaaS permettent un accès au logiciel à distance, sans contrainte d’installation locale, dès lors qu’une connexion internet est disponible. Il suffit d’avoir un login et un mot de passe pour accéder aux fonctionnalités et aux données.

Un logiciel en SaaS réduit également les contraintes de maintenance et permet des mises à jour régulières sans intervention technique.

La flexibilité et la scalabilité du SaaS améliorent donc l’efficacité et la productivité des utilisateurs.

Avantages pour les éditeurs SaaS

Pour les éditeurs, le SaaS génère des revenus récurrents grâce aux abonnements et facilite la maintenance ainsi que la scalabilité de l’infrastructure. En contrepartie, l’éditeur devient un maillon central de l’activité de ses clients, ce qui accroît leurs attentes en matière de fiabilité et de pérennité.

Un SaaS Escrow constitue ainsi un outil de confiance permettant de renforcer la continuité de service et la crédibilité auprès des clients.

Risques liés aux logiciels SaaS

• Le fournisseur peut être racheté par un concurrent, ce qui peut impacter la continuité du service ;
• Le fournisseur cesse de payer les services d’hébergement, mettant en danger l’accès aux données ;
• Une défaillance technique du logiciel lui-même ou de son hébergeur entraîne une perte d’accès aux données et à l’application ;
• Le fournisseur de logiciel cesse purement et simplement d’exister, par cessation d’activité ou faillite.

 

Pourquoi l’entiercement est essentiel pour le SaaS

Dans ce contexte, l’entiercement SaaS constitue un mécanisme structurant permettant d’anticiper les scénarios de défaillance et d’encadrer contractuellement l’accès aux actifs nécessaires à la poursuite de l’activité.

Sécurité pour les utilisateurs

Le SaaS Escrow permet au client de récupérer les éléments nécessaires à l’exploitation du logiciel cloud et les données associées en cas de défaillance du fournisseur. Il contribue ainsi à limiter les risques de rupture d’activité et à sécuriser la continuité des opérations, ces éléments comprenant notamment le code source du logiciel, la documentation technique, les identifiants techniques et les clés API, ainsi que le plan de migration et de sauvegarde des données cloud.

Confiance et crédibilité pour les éditeurs

Proposer un contrat de SaaS Escrow permet à l’éditeur de rassurer ses prospects et ses clients. Cela constitue un signal de sérieux et d’engagement en matière de continuité de service. Le contrat d’entiercement n’implique en aucun cas de transfert de propriété intellectuelle : l’éditeur demeure pleinement propriétaire du logiciel, du code source et de l’ensemble des éléments qu’il a développés. L’accès accordé au bénéficiaire est strictement limité aux hypothèses prévues au contrat et a pour seul objet d’assurer la continuité ou la reprise de l’exploitation du service. En dehors de ces cas encadrés, les droits de propriété intellectuelle de l’éditeur restent intégralement préservés.

 

Les composants clés d’un contrat de SaaS Escrow

La mise en place d’un contrat de SaaS Escrow repose sur plusieurs composantes essentielles qui doivent être définies avec précision afin d’assurer son efficacité juridique et opérationnelle.

Le choix du tiers de confiance

Le tiers de confiance doit garantir un haut niveau de sécurité, de confidentialité et de conformité réglementaire. Un dépôt numérique chiffrés et stocké en archivage électronique, la protection des données en transit et au repos, ainsi que la détention de certifications reconnues, telles que l’ISO 27001, constituent des prérequis indispensables.

L’Agence pour la Protection des Programmes (APP) intervient en tant que tiers de confiance reconnu, accompagnant depuis 1982 les éditeurs et les utilisateurs dans la protection de leurs actifs numériques. Son expertise en matière de protection des logiciels et sa connaissance approfondie des enjeux juridiques et techniques liés au SaaS en font un partenaire clé pour la mise en place de contrats d’entiercement adaptés aux nouveaux modèles logiciels.

Les documents et données déposés dans un SaaS Escrow

Un contrat de SaaS Escrow prévoit le dépôt d’un ensemble d’éléments permettant d’assurer la continuité ou la reprise du service. Parmi ces éléments, le plan de migration occupe une place centrale.

Le plan de migration décrit de manière structurée les modalités permettant au client de poursuivre l’exploitation du logiciel ou de transférer le service vers un autre environnement en cas de défaillance du fournisseur SaaS. Il précise notamment les étapes techniques à suivre, les prérequis nécessaires, les dépendances éventuelles avec des services tiers, ainsi que les délais estimés pour la reprise ou la transition du service, afin de permettre au client d’organiser concrètement la continuité ou la migration de la solution en cas de défaillance du fournisseur SaaS.

Conditions de libération

Le contrat doit encadrer strictement les situations dans lesquelles le bénéficiaire est autorisé à accéder aux éléments déposés. La définition de critères précis permet de protéger le client en cas de défaillance avérée du fournisseur, tout en préservant les intérêts de l’éditeur et en évitant toute transmission injustifiée de ses actifs. Ce mécanisme inclut notamment la libération du code source, définissant clairement quand et comment le bénéficiaire peut y accéder.

Mise à jour des éléments déposés et bonnes pratiques

Pour être réellement efficace, un SaaS Escrow doit s’inscrire dans une démarche opérationnelle cohérente avec le cycle de vie du logiciel. Les éléments déposés doivent être maintenus à jour afin de refléter les évolutions du code, des configurations techniques et, le cas échéant, des données concernées.

Il est recommandé de définir contractuellement des modalités de mise à jour du code source et des informations techniques associées, en particulier lorsque le logiciel fait l’objet de mises à jour fréquentes. Cette approche permet de garantir que les éléments déposés restent exploitables et pertinents en cas d’activation de l’entiercement.

Sécurité et conformité des données

Les données sensibles hébergées dans le cloud doivent faire l’objet de mesures strictes de sécurité et de conformité, intégrées au contrat de SaaS Escrow. Cela inclut notamment le respect des obligations en matière de protection des données, la définition des responsabilités des parties et l’encadrement des accès aux informations déposées, afin de garantir un niveau de protection adapté aux exigences réglementaires et opérationnelles.

 

Le SaaS Escrow : outil contractuel stratégique pour les environnements cloud

Le contrat de SaaS Escrow est un dispositif structurant pour encadrer les relations entre éditeurs de solutions cloud et clients utilisateurs. Adapté aux spécificités du modèle SaaS, il ne se limite pas au dépôt d’un code source, mais prend en compte l’ensemble des éléments nécessaires à la continuité ou à la reprise de l’exploitation du service, incluant l’environnement technique, les accès, la documentation et, le cas échéant, les données hébergées.

En anticipant contractuellement les scénarios de défaillance du fournisseur, le SaaS Escrow permet de sécuriser l’accès aux actifs numériques et de limiter les risques de rupture d’activité. Il s’inscrit en complément d’autres mécanismes contractuels, tels que les clauses de réversibilité des données, afin d’apporter une réponse cohérente aux enjeux de continuité de service propres aux logiciels cloud.

Dans ce cadre, le rôle du tiers de confiance est central. L’Agence pour la Protection des Programmes intervient comme acteur indépendant et reconnu de l’entiercement, disposant d’une certification ISO 27001 et d’une expertise en matière de protection des logiciels et des actifs numériques. Depuis plus de quarante ans, l’APP accompagne ses membres dans la protection de leurs créations, la valorisation de leurs actifs immatériels et la continuité de leur activité, en proposant des dispositifs d’entiercement adaptés aux évolutions technologiques et aux exigences juridiques du numérique.

 

A propos de l’auteure

Marine Yborra est Directrice Marketing de l’Agence pour le Protection des Programmes. Spécialiste du branding et de l’activation de marques, elle possède une expérience internationale dans le BtoB et le BtoC.

 

 

(1) En 2024, le marché global du SaaS était estimé à 317 milliards de dollars et pourrait atteindre 1 229 milliards de dollars d’ici à 2032 selon Fortune Business Insights, https://www.fortunebusinessinsights.com/software-as-a-service-saas-market-102222

Que vous soyez prestataire IT ou client acheteur de solutions numériques, il est essentiel de pouvoir décrypter l’état de la jurisprudence pour adapter vos pratiques contractuelles. Vous trouverez ci-dessous les principaux enseignements à tirer de l’année judiciaire écoulée en matière de projets digitaux.

 

Les 6 enseignements clés à retenir

• Le devoir de conseil du prestataire informatique est étendu et renforcé, en particulier en phase précontractuelle, avec une exigence accrue d’analyse des besoins, de faisabilité et de compatibilité des solutions.
•  La résiliation anticipée par le client n’est légitime que s’il a respecté ses propres obligations, notamment son devoir de collaboration et le paiement des prestations.
• Les juges tendent à qualifier de plus en plus les obligations des prestataires IT en obligations de moyens (voire de moyens renforcée) plutôt qu’en obligations de résultat, en raison de la complexité technique des projets et de la nécessaire collaboration du client. La qualification contractuelle reste possible, mais elle doit être cohérente avec la réalité technique des prestations.
• La conformité au RGPD est désormais appréhendée comme une obligation contractuelle dont la violation peut justifier la résolution du contrat.
• La signature d’un procès-verbal de recette ne libère pas le prestataire de son obligation de délivrance et n’empêche pas le client d’invoquer des dysfonctionnements ultérieurs.
• La sécurisation de la sortie du contrat est déterminante, les résiliations prématurées ou mal préparées, ainsi que les clauses limitatives de responsabilité ou d’indemnité de sortie excessives, étant strictement contrôlées par le juge.

 

Enseignement n°1 : le devoir de conseil du prestataire est de plus en plus vaste et exigeant

1. Renforcement de l’obligation précontractuelle d’information

Quelques décisions ont été rendues en 2025 illustrant la sévérité des tribunaux à l’égard des fournisseurs lorsqu’il s’agit de vérifier s’ils ont délivré au client informations et conseils.

Ainsi, dans son arrêt du 28 mai 2025 (RG n°21/08394), la Cour d’appel de Lyon a jugé, à propos d’un projet d’intégration d’un ERP, que le prestataire avait « manqué à son devoir précontractuel de conseil en ne s’informant pas suffisamment des attentes de sa cliente et en lui fournissant un produit qui ne correspondait pas à celles-ci ». L’arrêt relève en outre « qu’en sa qualité de professionnel, il lui appartenait de vérifier l’adéquation de son produit aux besoins du client avant la signature du contrat et non une fois le progiciel installé ».

L’arrêt est intéressant au regard des conséquences – lourdes – du manquement par le prestataire à son devoir précontractuel d’information, la Cour retenant qu’une telle défaillance a « entraîné l’erreur de la [cliente] sur les qualités essentielles du produit informatique, constitutive d’un vice du consentement (…) la nullité du contrat est encourue, laquelle entraîne les restitutions réciproques ».

Dans son arrêt du 24 avril 2025 (RG n°20/12936), la Cour d’appel d’Aix-en-Provence a jugé, à propos d’un prestataire chargé du développement d’un logiciel spécifique, « qu’il lui appartenait, avant de s’engager, d’étudier la faisabilité de sa mission et des prestations qu’[il] offrait », en s’assurant notamment de la compatibilité de sa solution avec les logiciels existants.

Enfin, dans son arrêt du 5 juin 2025 (RG n°24/00139), la Cour d’appel de Rouen a reproché au prestataire de ne pas avoir réalisé « l’étude des prérequis » et exigé de ce dernier, « avant de proposer sa solution informatique » qu’il « établi[sse] quels étaient les besoins effectifs [du client] ».

Conseil pratique 

Ces décisions montrent que l’on attend toujours plus du fournisseur, qui doit procéder – avant la signature du contrat et non une fois le progiciel installé – aux vérifications préalables et identifier les potentiels problèmes de compatibilité de son outil avec ceux en place chez le client. Procéder à un audit préalable du SI du client et réaliser une démonstration de sa solution avant de signer le contrat apparaissent comme autant de bonnes pratiques pour le prestataire.

 

2. Précisions sur les contours de l’information précontractuelle

Dans son arrêt du 14 mai 2025 (n°23-17.948), la Cour de cassation a livré son interprétation restrictive de l’article 1112-1 du Code civil relatif au devoir d’information précontractuelle, énonçant qu’« il résulte de l’article 1112-1 que le devoir d’information précontractuelle ne porte que sur les informations qui ont un lien direct et nécessaire avec le contenu du contrat ou la qualité des parties, et dont l’importance est déterminante pour le consentement de l’autre partie ». Pour qu’une information entre dans le champ du devoir précontractuel, elle doit à la fois avoir un lien direct et nécessaire avec le contenu du contrat ou la qualité des parties et revêtir une importance déterminante. Ce faisant, la solution pose une exigence de double preuve, le lien direct et nécessaire et le caractère déterminant de l’information étant deux choses distinctes.

Conseil pratique 

La question probatoire devrait être le terrain de vives discussions, ce qui doit inciter les parties à formaliser leurs négociations précontractuelles (lettre d’intention, promesse, échange de mails, etc.) et à soigneusement conserver l’historique de l’ensemble des points soulevés en phase précontractuelle.

 

 

Enseignement n°2 : la résiliation anticipée par le client reste conditionnée au respect par le client de ses propres obligations

1. Résiliation injustifiée en cas de manquement par le client à son devoir de collaboration

Par arrêt du 13 mars 2025 (RG n°21/08684), la Cour d’appel de Lyon a rappelé qu’un client qui méconnaît son obligation de collaboration aura toutes les difficultés à reprocher un manquement au prestataire. La Cour a ainsi débouté l’acquéreur d’une solution informatique qui se plaignait d’une incompatibilité du progiciel acquis avec ses matériels et d’une inadéquation avec ses besoins, car il avait lui-même manqué à son devoir de collaboration en refusant notamment de valider les interventions sur sites, d’installer un module du logiciel et de créer son compte sur la solution en question, ce qui a entravé le bon déroulement du projet.

Conseil pratique

Un client mécontent de la solution livrée et qui décide de mettre fin au contrat passé avec son prestataire doit s’assurer au préalable qu’il a lui-même respecté son obligation de collaboration (en procédant aux validations et retours, en fournissant les informations nécessaires pour que le prestataire puisse mener à bien sa mission, etc.). A défaut, il risque d’être mal fondé à opposer l’exception d’inexécution à son prestataire pour justifier la résiliation anticipée.

2. La suspension par le client du règlement des factures dues peut se retourner contre lui

Dans cette affaire, l’acquéreur d’un ERP déplorait l’incapacité de son prestataire à délivrer une solution logicielle complète, dans les délais convenus. Le client a donc notifié sa volonté de résilier le contrat, ce que le prestataire a contesté. L’affaire a été portée devant la Cour d’appel de Paris qui, par arrêt du 28 mars 2025 (RG n°22/17649), a jugé que le prestataire avait satisfait à son obligation de moyens et que, face au décalage important du règlement par le client de l’acompte puis de ses propres prestations, il avait dû décaler ses interventions. En refusant de régler les factures, le client a manqué à son obligation de collaboration, ce qui a impacté le bon déroulement du projet et a obéré les griefs qu’il opposait à son prestataire. C’est donc aux torts exclusifs du client que le contrat a été résilié.

Conseil pratique 

Dans le cadre de sa stratégie (pré)-contentieuse, un client mécontent de la qualité des prestations fournies devrait prendre le temps de la réflexion avant de suspendre le paiement des factures, une telle décision pouvant fragiliser sa position, voire se retourner contre lui.

 

3. Le refus par le client de régulariser un contrat de maintenance peut caractériser un comportement fautif de sa part

Dans cette affaire (CA Paris, 21 mars 2025, RG n°22/17566), un client se plaignant de dysfonctionnements des sites développés et livrés par son prestataire s’est vu reproché d’avoir refusé de régulariser un contrat de maintenance, ce qui lui aurait permis de corriger les défaillances dont il se prévalait. La Cour a relevé que la phase de « garantie post-production (…) de deux mois » prévue au contrat était expirée et que les corrections apportées aux anomalies avaient donc été réalisées en dehors de tout cadre contractuel. La Cour a ensuite jugé qu’en refusant de signer un contrat maintenance, le client a « privé son prestataire de la possibilité d’intervenir dans ce cadre pour remédier aux « bugs » divers qui pouvaient être relevés », ce qui l’a conduit à écarter toute responsabilité du prestataire au titre des perturbations rencontrées.

Conseil pratique

Les parties à un projet informatique ont tout intérêt à bien identifier ls prestations réalisées par le fournisseur au titre de la garantie post-production et celles couvertes par la maintenance à proprement parler, ces dernières nécessitant en principe la signature d’un contrat séparé. La prudence doit d’autant plus être de mise que le refus du client de mettre en place une tierce maintenance applicative peut s’analyser comme un manquement à son devoir général de loyauté contractuelle et obérer les griefs qu’ils pourraient opposer à son prestataire.

 

 

Enseignement n°3 : qualification des obligations du prestataire : vers une tendance à moins de « résultat » et plus de « moyens renforcée » ?

 

1. Qualification de l’obligation du prestataire en obligation de moyens

Dans un arrêt du 3 octobre 2025 (RG n°22/01534), la Cour d’appel de Paris a eu à se prononcer sur la nature de l’obligation du prestataire. Après avoir écarté la qualification prévue au cahier des charges, celui-ci n’étant ni signé, ni même visé au contrat, la Cour a ensuite relevé qu’« en raison de la complexité des opérations d’intégration des applications (…) la fourniture de ces prestations n’est pas présumée régie par une obligation de résultat mais par une obligation de moyens, sauf convention expresse entre les parties ». L’obligation de résultat est donc écartée.

La Cour d’appel de Colmar avait déjà, dans son arrêt du 15 janvier 2025 (RG n°23/02423), rappelé que « dans le cadre de l’installation d’un logiciel informatique, dès lors que l’obligation de délivrance du tiers suppose une collaboration active du client, il en résulte un aléa exclusif de la qualification d’obligation de résultat ». Les juges semblent donc tenir compte de la technicité des projets IT pour qualifier les obligations du prestataire.

Conseil pratique

Les parties ont la faculté de prévoir dans leur contrat la nature des engagements du prestataire, mais encore faut-il que la qualification retenue corresponde à la réalité technique de l’opération dans son ensemble et qu’elle ne contredise pas la portée de l’obligation essentielle du prestataire. Les rédacteurs et négociateurs doivent donc tenir compte du contexte et de leur participation respective à la réalisation des prestations concernées.

 

2. L’émergence de l’obligation de moyens renforcée

La qualification en obligation de moyens renforcée semble de plus en plus retenue par les Tribunaux.

Ainsi, dans son arrêt du 5 juin 2025 (RG n°24/00139), la Cour d’appel de Rouen a jugé qu’« eu égard à la complexité des prestations fournies dans un domaine particulièrement technique, le prestataire informatique est débiteur d’une obligation de conseil renforcée lorsque le client est peu expérimenté ». Et l’arrêt de préciser que « cette obligation, dont il lui appartient de démontrer qu’il y a satisfait, lui impose de rechercher les besoins réels de son client et il ne saurait contractuellement s’en dispenser ».

Dans une autre espèce, le Tribunal judiciaire de Mulhouse (27 mars 2025, RG n°22/00825) a retenu, à propos d’un « travail spécifique comportant une prestation intellectuelle » la qualification d’« obligation de moyen renforcée ». Cette qualification apparaît adaptée à la réalité des projets informatiques : en effet, il est a priori plus facile pour le fournisseur de démontrer qu’il n’a commis aucune faute dans l’exécution de ses obligations, plutôt que de faire peser sur le client non sachant la preuve que son prestataire n’a pas mis en œuvre les moyens promis.

 

 

Enseignement n°4 : Une non-conformité au RGPD peut caractériser un manquement contractuel justifiant la résolution du contrat

Par deux arrêts rendus le 13 mai (RG n°23/02044) puis le 11 juin 2025 (RG n°23/02206), la Cour d’appel de Bordeaux a prononcé la résolution d’un contrat, non pas sur le fondement classique d’une inexécution contractuelle mais sur celui d’une non-conformité au RGPD du site livré (en l’occurrence l’absence de bandeau de consentement pour les cookies de mesure d’audience et l’utilisation d’un reCaptcha collectant des données sans information préalable). La solution est suffisamment rare pour être signalée.

Conseil pratique

Cette solution, parce qu’elle érige la conformité au RGPD au rang d’obligation contractuelle dont la violation peut justifier l’anéantissement d’un contrat, devrait inciter les fournisseurs de solutions IT encore récalcitrants, à ne pas négliger la réglementation relative aux données personnelles dans le cadre des prestations qu’ils fournissent à leurs clients.

 

 

Enseignement n°5 : Portée relative de la signature d’un PV de recette

Une décision de la Cour d’appel de Versailles du 5 mars 2025 (RG n°23/01412) a confirmé la tendance jurisprudentielle – initiée en 2023 – selon laquelle la signature d’un PV de recette ne décharge pas le prestataire de son obligation de délivrance, laquelle n’est considérée comme pleinement exécutée qu’après mise au point effective de la chose vendue. La Cour a en effet relevé que « la signature par [le client] du procès-verbal de réception (…) ne saurait exonérer [le prestataire] » de sorte que « nonobstant la signature par [le client] du procès-verbal de réception précité, il ne peut en être déduit qu’à cette date, la solution était conforme et qu’il appartenait [au client] de dénoncer tout dysfonctionnement dans le délai de garantie de 3 mois ». Ainsi, la signature d’un PV de recette ne libère pas le prestataire de son obligation de délivrance, de sorte que, même en présence d’un PV de livraison signé, le client peut se plaindre de dysfonctionnements du système survenus postérieurement.

Conseil pratique

Les praticiens doivent tenir compte de cette jurisprudence, désormais bien établie, et veiller à bien documenter les phases de réception ainsi que les PV. Ils seront également inspirés de prévoir en amont les modalités techniques, organisationnelles et financières d’un éventuel accompagnement des clients par le prestataire au titre de la prise en main de la solution acquise.

 

Enseignement n°6 : Sécuriser la sortie du contrat

 

1. Le risque d’une résiliation prématurée

Dans son arrêt du 24 avril 2025 (RG n°24/01010), la Cour d’appel de Rouen a eu à se prononcer sur le bien-fondé de la résiliation par un client d’un contrat portant sur l’installation d’un logiciel de gestion et comptabilité assorti de prestations complémentaires. Pour juger la résiliation injustifiée, la Cour a tenu compte du timing dans lequel le client l’a notifiée à son prestataire, relevant que « dès lors que [le prestataire] a répondu à l’essentiel des demandes d’assistance [du client], rien ne permet d’affirmer qu’il ne serait pas parvenu, à brève échéance, à obtenir une installation fonctionnelle de la solution logicielle de sorte que la résolution intervenue le 13 avril 2022 a été faite à contretemps et prématurément et a porté sur une inexécution dont la Cour ne peut estimer qu’elle était suffisamment grave pour la motiver ». La décision de résilier un contrat ne doit donc pas être notifiée à contretemps et/ou prématurément.

Conseil pratique

Il est vivement recommandé aux parties à un contrat IT de bien se préparer avant de le résilier unilatéralement et de ne pas précipiter une telle décision. Le moment de la notification est en effet central, puisqu’il aura nécessairement des conséquences sur le caractère justifié ou au contraire injustifié de la résiliation. Pour éviter de résilier « trop tôt » ou au contraire « trop tard », les clients seront bien inspirés d’associer les équipes projet et opérationnelles à leur décision, en vérifiant en amont qu’une installation conforme du système à brève échéance n’était pas envisageable.

 

2. Le risque d’une résiliation mal préparée

Un client se plaignant de dysfonctionnements du matériel acquis a résilié le contrat de vente et de maintenance d’un système de caisse enregistreuse et a sollicité le remboursement de l’acompte versé. Saisie de l’affaire, la Cour d’appel de Bordeaux (12 juin 2025, RG n°23/02565), après avoir rappelé les principes applicables, a retenu qu’« il n’est pas démontré que le système d’encaissement était inutilisable et que les dysfonctionnements étaient dus au matériel lui-même et non aux modalités d’utilisation ». Les juges ont ici pointé une défaillance de la part du client dans l’administration de la preuve, ce dernier ne parvenant pas, « en l’absence de constat d’huissier ou d’expertise amiable », à établir l’existence de manquements suffisamment graves imputables au prestataire pour justifier la résolution du contrat.

Conseil pratique

Un client qui souhaite mettre fin à sa relation contractuelle avec un prestataire informatique doit disposer en amont d’un dossier probatoire solide et documenté et s’assurer qu’il est en mesure d’objectiver les perturbations et dysfonctionnements invoqués.

 

3. Champ d’application des clauses exonératoire de responsabilité, la vigilance est de mise

Une décision rendue à propos de l’aménagement contractuel de la responsabilité du prestataire particulièrement retenu l’attention. Il s’agit d’un arrêt de la Cour d’appel de Paris du 10 janvier 2025 (RG n°22/11677) rendu à propos de l’exécution d’un contrat de fourniture d’une solution de paiement en ligne sécurisé. Victime d’une série d’opérations frauduleuses, l’entreprise utilisatrice a décidé de ne plus travailler avec ce prestataire et l’a assigné en réparation. L’affaire a été portée devant la Cour d’appel.

Dans sa décision, la Cour a écarté la clause exonératoire de responsabilité du prestataire « au titre de tous dommages ou préjudices indirects ou immatériels qui pourraient résulter de l’inexécution ou de l’exécution défectueuse des services » au motif que c’est « un défaut d’information et de conseil qui était reproché [au prestataire] et non une défaillance de son interface ».

La clause exonératoire de responsabilité s’applique donc, semble-t-il, en cas de violation de l’obligation principale (en l’occurrence la fourniture d’une interface de gestion) et doit être rejetée en cas de manquement au devoir de conseil (accessoire de l’obligation principale). On peine à saisir une telle différence de régime, d’autant que la rédaction de la clause litigieuse semblait suffisamment large pour couvrir tous les manquements du fournisseur au cours de l’exécution du contrat et notamment les défaillances au titre du devoir de conseil.

Conseil pratique

Pour éviter toute déconvenue, les rédacteurs – surtout côté prestataire – veilleront à encadrer précisément les clauses limitatives de responsabilité, de manière à ce que l’obligation contractuelle de conseil ne soit pas mise de côté, quitte à spécifier expressément que l’exclusion de responsabilité s’applique également en cas de manquement au devoir de conseil.

 

4. Indemnité de sortie : attention à la requalification

Dans son arrêt du 13 mars 2025 (RG n°21/08684) la Cour d’appel de Lyon a eu à se prononcer sur la question de la qualification de l’indemnité de sortie (clause pénale vs clause de dédit).

Dans cette affaire, il a été jugé, à propos d’un contrat de mise à disposition d’une solution SaaS, que la clause de résiliation prévoyant le paiement par le client d’une somme égale à ce qui aurait été perçu en cas d’exécution jusqu’au terme du contrat revêt un caractère à la fois indemnitaire (évaluation forfaitaire du préjudice) et comminatoire (son montant élevé ne pouvant que contraindre le client à exécuter le contrat jusqu’à son terme) et devait donc s’analyser en une clause pénale.

La Cour a ensuite, comme le prévoit l’article 1231-5 du Code civil et après avoir tenu compte du comportement fautif du client dans le cadre de l’exécution de ses obligations, réduit son montant d’environ 50%.

Dans une autre affaire, la Cour d’appel de Toulouse (9 septembre 2025, RG n°23/02197) a jugé que l’indemnité de sortie réclamée par le prestataire à hauteur de 95% des sommes restant dues jusqu’à l’échéance du contrat répond à la qualification de clause pénale avant de juger un tel montant excessif et le ramener à 60% des dites sommes.

Conseil pratique

Ces deux arrêts doivent inciter les praticiens à soigner la rédaction de la clause de résiliation afin d’écarter toute difficulté ultérieure de qualification et, en tout état de cause, les encourager à faire preuve de modération dans la fixation des montants pour ne pas risquer d’attirer l’attention du juge qui pourrait, le cas échéant, réviser le montant de l’indemnité.

 

A propos de l’auteur

Olivier Pignatari est avocat spécialisé en droit de l’informatique et des nouvelles technologies, tant en conseil qu’en contentieux.

Ce qu’il faut retenir du dépôt auprès de l’Agence pour la Protection des Programmes (APP) 

• Le dépôt auprès de l’APP apporte la preuve de la titularité et de l’antériorité de vos droits sur vos créations numériques. 

• Il constitue un moyen de preuve juridique fiable pour  se prémunir contre les éventuelles revendications des tiers et agir en justice en cas de litige. 

• Les trois types de dépôt APP (standard, vérifié, contrôlé) offrent  différents niveaux de contrôle adaptés à chaque situation, notamment pour les logiciels et autres actifs numériques sensibles. 

• Les dépôts APP renforcent la valorisation de vos actifs immatériels en vous fournissant une cartographie complète de vos créations et en augmentant la crédibilité de votre entreprise auprès de vos partenaires et investisseurs. 

 

Pourquoi effectuer un dépôt auprès de l’APP ? 

Déposer votre création permet à la fois de la protéger juridiquement et de la valoriser.  

 La protection juridique de votre actif numérique 

D’un point de vue purement juridique :  

-Le dépôt contribue à prouver la titularité de vos droits sur votre création. Il permet d’identifier avec certitude le ou les titulaires de droits.  

-Le dépôt donne une date certaine à votre création. Il vous permet de démontrer que vous détenez l’antériorité des droits.  

-Le dépôt matérialise le contenu de votre création. Le dépôt est scellé et l’APP garantit qu’aucune modification n’est apportée au contenu tout au long de sa conservation. De plus, les dépôts successifs des mises à jour d’une même création vous permettent de retracer précisément son évolution. 

Effectuer un dépôt sert donc de moyen de preuve de manière à pouvoir agir en justice et prétendre à réparation en cas de préjudice.  

Dans certains cas, cela vous servira à éviter un procès long et couteux en vous permettant de régler le conflit à l’amiable.  

A l’inverse, cela permet également de vous prémunir contre d’éventuelles revendications de tiers. 

La valorisation de votre actif numérique 

Concernant la valorisation de vos créations, effectuer des dépôts successifs vous permet d’obtenir une cartographie de vos actifs numériques. Cette cartographie trace l’évolution des différentes versions de chaque création, mais aussi les éventuels changements de titularité des droits. 

Evidemment, procéder régulièrement au dépôt de vos créations et donc à la protection de vos droits de propriété intellectuelle traduit le sérieux et la fiabilité de votre entreprise, ce qui contribue à rassurer tous vos partenaires commerciaux, investisseurs et clients.  

 

Quels sont les différents types de dépôt proposés par l’APP ?

Pour protéger vos créations, l’APP vous propose 3 types de dépôts : le dépôt standard, le dépôt vérifié et le dépôt contrôlé.  

Chacun de ces trois types de dépôt est disponible sous forme numérique et sous forme physique.  

Un dépôt sous forme numérique est limité à 1 000 fichiers (sachant que par exemple une archive ZIP correspond à un seul fichier) et à 9.8 Go par dépôt.  

Pour un dépôt sous forme physique, le membre peut déposer autant de fichiers qu’il le souhaite et un tel dépôt est seulement limité à la capacité du support physique choisi par le membre.  

Le dépôt standard 

Le dépôt standard est une procédure de dépôt au cours de laquelle l’APP ne procède à aucune vérification ou contrôle du contenu déposé.  

Procédure 

Le membre remplit le formulaire de demande via son Espace Membre. Puis il transmet à l’APP sa création numérique soit via l’Espace membre pour un dépôt numérique, soit sur les supports physiques de son choix pour un dépôt physique.   

À l’issue de la procédure, le membre reçoit un certificat attestant du dépôt. 

Le dépôt vérifié 

Le dépôt vérifié est une procédure avancée de dépôt au cours de laquelle l’APP procède à un examen du contenu déposé.  

Les vérifications consistent à décompresser et à extraire une archive ZIP et à calculer l’empreinte électronique (checksum) de chacun des fichiers qu’elle contient.  

Procédure 

Le membre remplit un formulaire de demande. Puis il transmet à l’APP sa création numérique soit via un serveur SFTP pour un dépôt numérique, soit sur les supports physiques de son choix pour un dépôt physique.   

À l’issue de la procédure, le membre reçoit un certificat attestant du dépôt ainsi qu’un rapport de dépôt vérifié consignant les opérations effectuées, auquel est annexée la liste des fichiers déposés et leur empreinte. 

Le dépôt contrôlé

Le dépôt contrôlé est une procédure avancée de dépôt avec un niveau supérieur de vérification des éléments déposés.  

Ce type de dépôt est essentiellement utilisé pour le dépôt de logiciels entiercés. Pour un logiciel, les opérations de contrôle consistent à compiler les codes sources, installer les binaires générés et à procéder à des tests fonctionnels.  

L’objectif de ce dépôt est de s’assurer que les éléments déposés constituent un ensemble fonctionnel. En cas d’entiercement, l’objectif est aussi de s’assurer que cet ensemble fonctionnel est conforme à celui qui est installé chez l’utilisateur qui est le bénéficiaire de l’accès.  

Procédure 

Le dépôt contrôlé se déroule en 6 étapes : cadrage, préparation, dry-run (test à blanc), contractualisation, contrôle et dépôt. 

Le membre transmet à l’APP sa création numérique soit via un serveur SFTP pour un dépôt numérique, soit sur les supports physiques de son choix, pour un dépôt physique. 

À l’issue de la procédure, le membre reçoit un certificat attestant du dépôt ainsi qu’un rapport de dépôt contrôlé consignant les opérations effectuées.

 

Cas d’usage : l’intérêt du dépôt dans le cadre d’une levée de fonds 

Une start-up souhaite entamer des démarches pour lever des fonds. Dans cette optique, elle doit rassurer les éventuels investisseurs sur sa politique de protection de ses actifs immatériels. Il est primordial qu’elle s’assure de prévoir une protection adéquate pour chacun de ses actifs immatériels.  

Les risques liés à une protection insuffisante des actifs numériques 

Elle attache une grande importance à la protection de ses titres de brevet et de marque mais ce n’est pas forcément le cas concernant la protection de ses droits d’auteur sur ses actifs numériques. Cette situation présente des risques, d’autant plus que la start-up a fait appel à de nombreux intervenants internes et externes pour le développement de ses créations numériques, n’est pas l’unique titulaire de droits sur certains actifs et a mis en place plusieurs accords de licence.  

Le recours à l’APP pour protéger les actifs numériques 

Elle constate qu’il est nécessaire de procéder à des opérations de dépôt de ses actifs numériques et décide de faire appel à l’APP. 

Déposer auprès de l’APP lui permet évidemment d’obtenir un moyen de preuve de l’existence de ses droits et une cartographie complète de ses actifs, mais cela lui permet également de bénéficier de :  

-une gestion de ses relations mandataire/mandant ; 

-une gestion de ses relations de cotitularités ; 

-un suivi de l’évolution de la titularité des droits sur ses créations numériques ; 

-une gestion des accords d’entiercement prévus avec ses clients. 

Un signal de confiance envoyé aux investisseurs 

Réaliser ces démarches lui permet de témoigner du sérieux dont elle fait preuve en matière de valorisation et protection de ses actifs, ce qui contribue fortement à rassurer les futurs investisseurs.  

 

À propos de l’auteure 

Garance Gonnet-Prince est juriste en propriété intellectuelle à l’Agence pour la Protection des Programmes et spécialisée en dépôt probatoire.