Logiciels Software as a Service : Contrats Saas Editeurs / Utilisateurs

La qualification exacte du contrat SaaS continue d’alimenter un débat juridique actif notamment sur l’application du statut protecteur de l’agent commercial aux distributeurs de solutions SaaS.

Le modèle SaaS, par construction, n’implique ni transfert de copie ni droit perpétuel excluant la notion de vente telle qu’analysée par la CJUE (CJUE, 16 septembre 2021, aff. C-410/19, The Software Incubator c/ Computer Associates, dans la continuité de CJUE, 3 juillet 2012, aff. C-128/11, UsedSoft c/ Oracle).

Une décision anglaise favorise la qualification de location du fait de l’abonnement Saas limité dans le temps excluant au revendeur le statut d’agent commercial, réservé à la vente de marchandises. Ce raisonnement offre une grille de lecture transposable en droit français et européen. Les éditeurs et distributeurs ont intérêt à anticiper cette incertitude dans la rédaction de leurs contrats de distribution.

 La quasi-totalité des contrats SaaS comportent une clause de limitation de responsabilité, souvent plafonnée aux sommes versées au cours des douze derniers mois. Cette clause est valide entre professionnels en droit français, mais elle connaît des limites d’ordre public : elle ne saurait notamment exclure la responsabilité en cas de dol ou de faute lourde, ni vider de sa substance une obligation essentielle du contrat.

Les négociations portent généralement sur l’exclusion des dommages indirects — souvent rédigée trop largement et à circonscrire précisément —, sur les carve-outs obligatoires (faute lourde, dol, atteinte aux données personnelles), et sur l’adéquation du plafond au risque business réel plutôt qu’au seul montant du contrat.

La localisation des serveurs est devenue un paramètre stratégique de souveraineté numérique. L’hébergement auprès d’acteurs non européens expose les clients aux effets extraterritoriaux de législations étrangères, au premier rang desquelles le Cloud Act américain.

Si le risque de transfert vers les États-Unis a été partiellement atténué par les clauses contractuelles types de la Commission européenne et par la décision d’adéquation relative au Data Privacy Framework de 2023, la dépendance à des prestataires extra-européens demeure un enjeu réel, en particulier en période d’instabilité géopolitique.

Pour les SaaS les plus stratégiques, il peut être opportun de privilégier un hébergeur européen ou, à défaut, d’anticiper contractuellement des mécanismes de garantie de continuité de service.

Le contrat SaaS n’emporte par nature aucun transfert de propriété sur le logiciel : le client bénéficie d’un droit d’usage non exclusif, strictement encadré et non sous-licenciable (hors hypothèses de revente par un intégrateur ou un revendeur). Les activités de reproduction, décompilation ou ingénierie inverse sont en principe prohibées.

Si la propriété des données importées par le client ne fait généralement pas débat, celle des données d’usage générées par son activité sur la plateforme est plus délicate : ces données, une fois agrégées et analysées, représentent une valeur stratégique pour l’éditeur, qui peut chercher à les exploiter pour sa feuille de route produit ou, de plus en plus, pour l’entraînement de modèles d’intelligence artificielle. Le contrat doit donc définir précisément le régime de ces données d’usage et leur droit d’exploitation respectif. Lorsque ces données permettent d’identifier, directement ou indirectement, une personne physique, elles relèvent du régime RGPD et doivent s’inscrire dans un traitement conforme.

Pour les SaaS les plus stratégiques, une clause d’entiercement (escrow) peut être envisagée, donnant au client un accès conditionnel au code source en cas de défaillance de l’éditeur — sous réserve, toutefois, des limites pratiques de cette protection en mode SaaS.

Le mécanisme classique de protection du client en cas de défaillance de l’éditeur — le dépôt du code source auprès d’un tiers séquestre tel que l’Agence pour la Protection des Programmes (APP), assorti d’un contrat d’entiercement tripartite — a été conçu pour le monde du logiciel installé localement (on-premise). Dans ce contexte, l’accès au code source permettait effectivement au client de reprendre la main sur le logiciel et d’en assurer la maintenance par un autre prestataire.

Le passage au SaaS rebat profondément ces cartes. Le client SaaS ne dispose ni de copie exécutable ni de code source : il dépend non seulement du logiciel, mais aussi de l’infrastructure technique, des systèmes de sauvegarde et des choix stratégiques de l’éditeur. Un dépôt classique du code source y perd largement son intérêt pratique, pour deux raisons structurelles : un produit SaaS évolue en continu, rendant quasiment impossible la disponibilité d’un code à jour au moment du déclenchement du séquestre ; et un produit SaaS résulte d’une combinaison indissociable entre logiciel et hébergement, de sorte que la seule récupération du code source, sans l’infrastructure associée, exige un investissement de redéploiement considérable — généralement plus coûteux et plus long qu’un simple changement de prestataire.

Le dépôt garde néanmoins son sens pour les développements spécifiques réalisés pour le client, à condition qu’ils soient réutilisables de manière autonome (interfaces, API). De nouvelles formes de dépôt émergent également : dépôt de codes permettant la reprise en main du tenant du client, dépôt d’une copie des données traitées, voire, dans des cas extrêmes, dépôt d’une copie de l’infrastructure.

En tout état de cause, la protection du client en mode SaaS ne peut reposer sur le seul entiercement. Elle doit être complétée par d’autres garanties contractuelles : garanties d’accès, interdiction pour le prestataire de bloquer les accès ou de refuser la restitution des données, obligation d’information sur la feuille de route et les évolutions structurantes, et surtout définition d’un plan de sortie (exit strategy) anticipé dès la signature du contrat. Cette anticipation est d’autant plus stratégique pour les acteurs soumis à des règles de maîtrise des prestataires informatiques tiers, comme les entités relevant de DORA ou de NIS 2.

Au-delà du RGPD, plusieurs textes récents imposent directement de nouvelles obligations aux prestataires SaaS, qui doivent revoir en conséquence leurs pratiques contractuelles.

Data Act et loi SREN : concurrence et portabilité. Le Data Act (règlement UE 2023/2854) et la loi SREN définissent de façon quasi identique les « fournisseurs de services de traitement de données » et les « fournisseurs de services d’informatique en nuage », une notion qui couvre expressément les services SaaS. Ces textes cherchent à limiter les phénomènes de dépendance technologique (vendor lock-in) en encadrant les frais de changement de fournisseur (voir plus haut sur la réversibilité) et en imposant des obligations d’interopérabilité et de portabilité des données, via la mise à disposition d’interfaces dédiées.

La loi SREN comporte également des interdictions complémentaires : impossibilité d’établir des avoirs à durée indéterminée ou assortis d’une condition d’exclusivité, et interdiction de subordonner la vente d’un produit à la souscription d’un service cloud lorsque cela constitue une pratique commerciale déloyale (nouvel article L. 442-12 du Code de commerce).

Les prestataires cloud doivent en outre publier sur leur site internet les juridictions dans lesquelles les données pourraient être traitées, ainsi que les mesures prises pour empêcher l’accès par des autorités publiques extra-européennes — une information qui doit également figurer dans le contrat, avec mention des URL concernées.

La directive NIS 2 : cybersécurité renforcée. La directive (UE) 2022/2555 (NIS 2) renforce significativement les obligations de cybersécurité applicables aux prestataires SaaS par rapport au régime antérieur, dès lors qu’ils constituent des entités de taille moyenne ou grande au sens du droit européen. Ces entités relèvent du statut d’entité « essentielle » ou « importante » et sont soumises à une obligation de déclaration auprès de l’État membre de leur établissement principal, ainsi qu’à une obligation de notification des incidents de cybersécurité importants. La loi française de transposition reste, à ce jour, toujours attendue, ce qui crée une incertitude temporaire sur les modalités précises applicables aux acteurs français.

Les sanctions associées à ce nouvel arsenal réglementaire sont loin d’être symboliques : jusqu’à 3 % du chiffre d’affaires mondial pour certains manquements à la loi SREN, et jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires mondial pour les manquements des entités essentielles à NIS 2.

La jurisprudence récente illustre concrètement les points de friction les plus fréquents dans l’exécution des contrats SaaS.

Par un jugement du 17 juin 2025, le Tribunal des activités économiques de Paris a prononcé la résolution judiciaire de plusieurs contrats SaaS aux torts exclusifs du prestataire, sur le fondement des articles 1217 et 1219 du Code civil. Le tribunal a jugé que le défaut d’adéquation du logiciel aux besoins exprimés par le client pouvait constituer une inexécution suffisamment grave pour justifier la résolution, même en présence de clauses limitatives de responsabilité, et a rappelé que le devoir de coopération et d’assistance du prestataire, en particulier dans les projets de migration complexes, lui est pleinement opposable. Point notable : une clause contractuelle de résiliation n’interdit pas au juge de prononcer une résolution judiciaire de droit commun si les conditions en sont réunies.

Plus récemment, la Cour de cassation a précisé, dans un arrêt du 3 décembre 2025 (n° 24-17.537, publié au Bulletin), que le principe de réparation intégrale sans perte ni profit (article 1231-2 du Code civil) s’oppose à ce qu’un prestataire SaaS réclame le paiement de l’intégralité des sommes dues jusqu’au terme du contrat en cas de résiliation anticipée, dès lors que le service — rendu en continu — n’a pas été exécuté jusqu’à son terme.

Cette décision tempère une pratique contractuelle fréquente consistant à exiger le paiement intégral des échéances restantes en cas de rupture anticipée : en l’absence de clause pénale valablement stipulée, le prestataire devra démontrer sa perte réelle et son gain manqué plutôt que de se prévaloir d’un droit automatique au paiement intégral.