Modèle de contrat d’accès API gratuit (Word)

Sommaire

1. Quand utiliser ce contrat, et quand il ne convient pas
2. Ce que dit le droit français
3. Ce que contient ce modèle, article par article
4. Les pièges à éviter
5. Comment adapter ce modèle à votre situation
6. Ce que ce modèle ne remplace pas

Quand utiliser ce contrat, et quand il ne convient pas

Vous ouvrez votre API à des clients ou partenaires. Une société qui commercialise l’accès à son moteur de calcul, à son référentiel de données ou à sa brique de paiement fournit un service programmatique, facturé au forfait ou à l’usage. Le contrat fixe le périmètre de l’accès et de l’usage de l’API, les niveaux de service et le sort des données échangées. Il n’organise pas une cession de logiciel, mais un droit d’accès contrôlé et révocable.

Vous intégrez une API tierce dans votre produit. Une PME qui branche une API de signature électronique, une ETI qui alimente son application via une API de données de marché signe le même contrat, en position de client. La vigilance porte alors sur la disponibilité du service, la stabilité des versions et les conditions de sortie, pour ne pas voir une intégration critique s’interrompre sans recours.

L’API échange des données personnelles. Dès que l’interface transmet ou reçoit des données de clients, de salariés ou de prospects, la question de la sous-traitance au sens de l’article 28 du RGPD se pose. Le contrat doit alors préciser les finalités, les mesures de sécurité, la localisation des données et le sort des flux à la fin de la relation.

L’accès repose sur des clés et des quotas. L’authentification par clé, jeton ou certificat, et l’existence de limites d’appels, appellent des règles écrites : conditions de délivrance, de rotation et de révocation des accès, seuils de quotas, conséquences du dépassement. Ces mécanismes sont le cœur opérationnel du contrat d’accès.

Quand ce modèle ne convient pas. Si la relation consiste à céder la propriété d’un logiciel ou d’un code livré au client, elle relève d’un contrat de cession, non d’un accès. Si le fournisseur héberge et exploite une application complète accessible par navigateur, avec ou sans API accessoire, un contrat SaaS d’abonnement est plus adapté. Si l’API relève d’un service d’intermédiation en ligne entre professionnels, le règlement européen P2B ajoute des obligations dédiées. [À VÉRIFIER JURISTE : applicabilité concrète du règlement P2B et du Data Act au cas d’espèce.]

Ce que dit le droit français

Le contrat d’accès API est un contrat innommé. Il ne correspond à aucun contrat spécial du Code civil : il mêle une licence d’utilisation sur d’éventuels composants logiciels et une prestation de services d’accès technique. De nature sui generis (article 1105 du Code civil), il est régi par le droit commun des contrats réformé par l’ordonnance de 2016. Sa validité suppose un consentement libre, un contenu licite et certain (article 1128 du Code civil) et le respect de l’obligation d’information précontractuelle de l’article 1112-1.

Un contrat d’adhésion connaît des garde-fous. Beaucoup d’accès API reposent sur des conditions non négociables, prérédigées par le fournisseur : le contrat est alors un contrat d’adhésion au sens de l’article 1110 du Code civil. Toute clause créant un déséquilibre significatif entre les droits et obligations des parties est réputée non écrite (article 1171 du Code civil), sanction cumulable avec l’action pour déséquilibre significatif entre partenaires commerciaux de l’article L. 442-1 du Code de commerce. Une clause de révocation ou de modification purement discrétionnaire est ici en première ligne.

Les composants logiciels et les données obéissent au droit de la propriété intellectuelle. Un kit de développement (SDK) ou une bibliothèque cliente mis à disposition restent protégés au titre des articles L. 122-6 et L. 122-6-1 du Code de la propriété intellectuelle, qui réservent à l’auteur la reproduction et l’adaptation tout en préservant l’interopérabilité. Si l’API expose une base de données, le producteur bénéficie du droit sui generis des articles L. 341-1 et suivants du même code. Le contrat concède alors une licence non exclusive, non cessible, avec réserve de propriété.

Le fournisseur peut être sous-traitant de données. Lorsqu’il traite des données personnelles pour le compte du client, l’article 28 du RGPD impose un acte juridique contraignant : finalités et durée, mesures de sécurité, encadrement de la sous-traitance ultérieure, sort des données en fin de contrat, droit d’audit. Le défaut d’un tel acte expose aux sanctions de l’article 83 du RGPD, en lien avec la loi Informatique et Libertés du 6 janvier 1978. La protection des données n’est pas un accessoire du contrat, mais une obligation autonome.

Les clauses limitant la responsabilité restent encadrées. Entre professionnels, un plafond et l’exclusion des dommages indirects sont licites, dans les bornes des articles 1231-1 et suivants du Code civil. Mais une clause qui prive de sa substance l’obligation essentielle du fournisseur est réputée non écrite (article 1170 du Code civil, dans la lignée de la jurisprudence Chronopost puis Faurecia). Une limitation de responsabilité dérisoire face à une API critique risque donc d’être écartée.

La sortie et la durée obéissent au droit commun. En durée indéterminée, chaque partie peut résilier moyennant un préavis raisonnable (article 1211 du Code civil) ; la résolution pour inexécution suit les articles 1224 et suivants. Aucun texte général n’impose la réversibilité, mais son absence laisse le client sans moyen de récupérer ses données. Selon la nature de l’API, le règlement P2B (2019/1150) et le Data Act (2023/2854) ajoutent des obligations d’information et de portabilité. [À VÉRIFIER JURISTE : applicabilité du P2B et du Data Act selon le service concerné.]

Ce que contient ce modèle, article par article

Article 1. Objet et périmètre de l’API. L’article fondateur décrit l’interface mise à disposition, les points d’accès (endpoints) couverts, les versions supportées et renvoie à une documentation technique. Un périmètre flou nourrit les litiges sur ce qui relève de l’accès convenu et ce qui appelle une option facturée.

Article 2. Droit d’accès et licence. Le modèle concède un droit d’accès et une licence d’utilisation non exclusifs, non cessibles et limités à la durée du contrat, portant sur l’API et ses éventuels composants clients (SDK, bibliothèques). Il rappelle la réserve de propriété du fournisseur, dans le cadre des articles L. 122-6 et suivants du Code de la propriété intellectuelle.

Article 3. Clés, authentification et quotas. Conditions de délivrance, de rotation et de révocation des clés ou jetons, seuils de quotas et de limites d’appels (rate limits), mode de comptage vérifiable, conséquences du dépassement. Cet article distingue la suspension d’urgence en cas d’abus de la résiliation ordinaire soumise à préavis.

Article 4. Niveaux de service et disponibilité. Taux de disponibilité cible, fenêtres de maintenance, délais de rétablissement et d’intervention, pénalités éventuelles. La disponibilité relève ici d’une obligation de moyens renforcée : l’article convertit l’engagement en obligation mesurable via un SLA écrit.

Article 5. Support, versions et évolutions. Canaux et horaires de support, délais de prise en charge des incidents, politique de versions et de dépréciation des points d’accès obsolètes, préavis avant tout changement susceptible de casser l’intégration du client. La stabilité des versions est un enjeu de continuité aussi fort que la disponibilité.

Article 6. Prix, facturation et révision. Montant de l’accès, modalités de calcul à l’usage le cas échéant, périodicité, délai de paiement conforme au plafond de l’article L. 441-10 du Code de commerce, mécanisme de révision de prix encadré. Un modèle à l’usage appelle un comptage transparent et opposable.

Article 7. Sécurité informatique et données personnelles. L’article renvoie à un acte de sous-traitance conforme à l’article 28 du RGPD, détaille les mesures de sécurité, la localisation des données et l’encadrement des transferts. Il précise le régime des données transitant par l’API et le partage des responsabilités en cas d’incident.

Article 8. Confidentialité. Chaque partie protège les informations sensibles reçues de l’autre. Les clés d’accès, la documentation technique et les données échangées justifient une obligation ferme, distincte de l’engagement de sécurité technique.

Article 9. Responsabilité. Plafond, exclusion des dommages indirects, et rappel que la limitation ne joue ni pour la faute lourde ou dolosive, ni au point de vider l’obligation essentielle de sa substance (articles 1170 et 1231-1 du Code civil).

Article 10. Durée, résiliation et réversibilité. Durée, conditions de reconduction et de résiliation, préavis, puis organisation de la sortie : restitution des données dans un format exploitable, période de transition et suppression des données par le fournisseur avec preuve.

Article 11. Force majeure et droit applicable. Reprise des conditions de la force majeure, droit français, langue du contrat et attribution de juridiction, précédées le cas échéant d’une étape de règlement amiable.

Les pièges à éviter

Autoriser une révocation des clés sans préavis. Une clause qui permet au fournisseur de couper l’accès à tout moment, sans motif ni préavis, expose le client à voir son intégration s’interrompre du jour au lendemain. Le contrat doit séparer la suspension d’urgence, immédiate mais réservée à l’abus avéré ou à la menace de sécurité, de la résiliation ordinaire, soumise à un préavis raisonnable. Une révocation discrétionnaire risque d’être réputée non écrite au titre de l’article 1171 du Code civil.

Se contenter d’un fair use non chiffré. Renvoyer à un usage raisonnable sans fixer de quotas laisse le fournisseur seul juge du dépassement et autorise une coupure discrétionnaire. Des limites d’appels mesurables, un mode de comptage vérifiable et une conséquence prédéfinie du dépassement, facturation, bridage ou suspension après alerte, protègent les deux parties. Un seuil implicite est une source de litige programmée.

Oublier la réversibilité et la restitution des données. Un contrat qui ne prévoit ni format de récupération, ni délai, ni suppression des données laisse le client captif à l’échéance. La restitution des données doit être organisée à l’avance, dans un format exploitable, et la suppression par le fournisseur documentée par une preuve. Pour une intégration critique, la sortie se prépare avant qu’elle ne devienne urgente.

Négliger la sous-traitance ultérieure RGPD. Le fournisseur d’API s’appuie souvent lui-même sur des hébergeurs ou des sous-traitants tiers. Traiter des données personnelles sans encadrer cette chaîne, ni recueillir l’autorisation du client, expose les deux parties aux sanctions de l’article 83 du RGPD. La localisation, les transferts hors Union européenne et le sort des données doivent être documentés, pas simplement évoqués.

Fixer un plafond de responsabilité dérisoire. Un plafond limité à quelques mois d’accès, face à une API dont dépend une fonction critique du client, risque d’être écarté par le juge comme privant l’obligation essentielle de sa substance. Le plafond doit rester proportionné à l’enjeu réel du service et à la sensibilité des données échangées.

Comment adapter ce modèle à votre situation

Quelques champs se renseignent systématiquement : l’identité des parties, la description de l’API et de son périmètre, le prix et ses modalités, la durée de l’accès. Le reste du texte convient à la plupart des accès API courants entre professionnels.

Le régime des clés et des quotas mérite le plus grand soin. C’est lui qui départage un accès stable d’une intégration exposée à une coupure imprévisible. Pour une API critique intégrée en production, fixez des seuils clairs, un préavis avant révocation ordinaire et une politique de versions protectrice ; pour un accès de test ou de développement, un cadre plus souple suffit.

L’encadrement des données s’ajuste selon la nature des flux. Dès que l’API échange des données personnelles, l’acte de sous-traitance conforme à l’article 28 du RGPD n’est pas optionnel, et la localisation comme les transferts hors Union européenne doivent être arrêtés noir sur blanc. Si l’API expose une base de données protégée, ajoutez une clause précisant l’étendue de la licence d’utilisation et la réserve de propriété du producteur.

Adaptez enfin la clause de niveaux de service au caractère réel de l’API. Un accès non critique se satisfait d’une obligation de moyens simple, quand une API de paiement ou de production impose un taux de disponibilité chiffré, des délais de rétablissement courts et un mécanisme de pénalités opposable.

Ce que ce modèle ne remplace pas

Un modèle est un point de départ, pas un avis. Il ne connaît ni la criticité exacte de votre intégration, ni la nature des données échangées, ni le rapport de force entre les parties. Trois situations appellent une relecture par un professionnel : une API relevant d’un service d’intermédiation en ligne soumis au règlement P2B, ou d’un accès aux données visé par le Data Act, dont l’applicabilité concrète doit être vérifiée ; un traitement de données à grande échelle ou de données sensibles, qui appelle un acte de sous-traitance renforcé et une analyse d’impact ; et un contrat international où la localisation des données, le droit applicable et la juridiction compétente sont eux-mêmes en négociation.

C’est la raison pour laquelle ce modèle signale ses propres limites, plutôt que de se présenter comme suffisant en toute circonstance.