Modèle de conditions d'utilisation API gratuit

Présentation

Les conditions d'utilisation d'API (CGU API) encadrent l'accès et l'usage d'une interface de programmation applicative (API) mise à disposition de développeurs ou d'entreprises tierces. Elles définissent les règles d'usage technique et juridique de l'API — limites de volumétrie, gestion des clés d'authentification, usages interdits, propriété des données transmises — indépendamment de tout engagement contractuel de niveau de service. Ce document se distingue d'un contrat d'accès commercial à une API : il s'agit d'un cadre d'utilisation généralement unilatéral, opposable par acceptation, plus proche dans sa nature de conditions générales d'utilisation que d'un contrat négocié entre deux parties. Juridiquement, ces conditions relèvent du droit commun des contrats (articles 1101 et suivants du Code civil) et, lorsqu'elles s'adressent à des utilisateurs non professionnels ou à des professionnels agissant hors de leur domaine d'activité principale, potentiellement du droit de la consommation. Une attention particulière doit être portée à la propriété des données qui transitent par l'API : les données appartenant à l'utilisateur de l'API (ou à ses propres clients) doivent être clairement distinguées des données générées ou enrichies par le fournisseur de l'API, et le régime de chacune doit être précisé. Dès lors que des données à caractère personnel transitent par l'API, le RGPD s'applique et impose, selon les rôles respectifs des parties, la conclusion d'un accord de traitement des données distinct. Quand l'utiliser : pour tout fournisseur qui met à disposition une API — gratuite, freemium ou avec des quotas d'usage — à destination de développeurs tiers, de partenaires techniques ou d'entreprises intégrant cette API dans leurs propres produits, sans qu'il s'agisse nécessairement d'un accès commercial structuré avec engagement de niveau de service (voir dans ce cas le contrat d'accès API dédié). Parties : le fournisseur de l'API, qui définit et fait évoluer unilatéralement les règles d'usage, et l'utilisateur de l'API (développeur, société, plateforme tierce), qui accède à l'API par le biais d'une clé ou d'un jeton d'authentification. Clauses essentielles : les modalités d'obtention et de gestion des clés API (délivrance, révocation, confidentialité) ; les limites d'usage et le mécanisme de rate limiting (nombre d'appels autorisés par unité de temps, comportement en cas de dépassement) ; les usages autorisés et interdits de l'API (interdiction de revente non autorisée, de scraping massif, de contournement des quotas, d'usage à des fins illicites) ; la propriété des données transitant par l'API, en distinguant les données de l'utilisateur, les données de ses propres utilisateurs finaux et les données générées par le fournisseur ; les conditions de modification ou de dépréciation de l'API (delai de préavis avant changement de version, fin de support d'une version antérieure) ; la limitation de responsabilité du fournisseur, en particulier l'absence de garantie de disponibilité continue lorsque l'API est fournie à titre gratuit ; et les conditions de suspension ou de résiliation de l'accès en cas de manquement de l'utilisateur. Erreurs à éviter : ne pas préciser de rate limiting clair, ce qui expose à des usages abusifs et à des litiges sur les motifs de blocage d'un utilisateur ; omettre la clause de propriété des données transmises via l'API, laissant planer une ambiguïté sur qui peut réutiliser quelles données ; confondre CGU d'API unilatérales et véritable contrat d'accès commercial avec engagement de SLA — si l'API est facturée avec un engagement de disponibilité, un contrat d'accès API distinct est plus adapté ; et ne pas prévoir de préavis avant dépréciation d'une version de l'API, ce qui peut casser sans avertissement les intégrations des utilisateurs tiers.

Informations à personnaliser

• Nom ou raison sociale du fournisseur de l'API

• Numéro SIREN du fournisseur

• Adresse du fournisseur

• Nom de l'API

• Description fonctionnelle de l'API

• Limite de requêtes par unité de temps (rate limiting)

  Ex. : 1000 requêtes par heure et par clé API.

• Conséquence en cas de dépassement de quota

• Usages spécifiquement interdits

• Régime de propriété des données transitant par l'API

• Délai de préavis avant dépréciation d'une version

• Régime tarifaire de l'accès à l'API

  Gratuit, freemium avec quota, ou payant.

• Date d'entrée en vigueur des conditions

Personnalisez votre modèle

Questions fréquentes

Que sont les conditions d'utilisation d'une API ?

Ce sont des règles d'usage, généralement unilatérales, que le fournisseur d'une API impose aux développeurs ou entreprises qui souhaitent y accéder : limites de volumétrie, usages interdits, gestion des clés d'authentification, propriété des données transmises.

Quelle différence entre CGU d'API et contrat d'accès API ?

Les CGU d'API sont un cadre unilatéral, opposable par acceptation, souvent utilisé pour un accès gratuit ou freemium. Un contrat d'accès API commercial, distinct, engage le fournisseur sur un niveau de service (SLA) et du support, en contrepartie d'un paiement — il est plus adapté lorsqu'il existe un engagement de disponibilité contractuel.

Qu'est-ce que le rate limiting ?

C'est la limitation du nombre de requêtes qu'un utilisateur peut adresser à l'API sur une période donnée. Il protège l'infrastructure du fournisseur et garantit un usage équitable entre tous les utilisateurs de l'API.

Qui est propriétaire des données transmises via l'API ?

Cela dépend de ce que prévoient les conditions d'utilisation : en général, les données propres à l'utilisateur de l'API (et à ses propres clients finaux) lui restent acquises, tandis que les données générées ou enrichies par le fournisseur peuvent relever d'un régime distinct. Ce point doit être précisé explicitement.

Un accord de traitement des données (DPA) est-il nécessaire pour une API ?

Dès lors que des données à caractère personnel transitent par l'API, le RGPD s'applique. Selon le rôle de chaque partie (responsable de traitement ou sous-traitant), un DPA distinct peut être nécessaire pour encadrer ce traitement.

Le fournisseur peut-il modifier ou arrêter une version de l'API sans préavis ?

Il est recommandé, et souvent attendu par les utilisateurs, que le fournisseur prévoie un délai de préavis raisonnable avant toute dépréciation d'une version de l'API, afin de laisser aux utilisateurs le temps d'adapter leurs intégrations.

Modèles associés