Conditions d’utilisation d’une API : ce qu’elles doivent contenir

Les conditions d’utilisation d’une API sont un contrat, pas une documentation

Page du service : Commerce numérique et IA : un avocat pour les conditions générales, la vie privée et la prospection directe.

Une interface de programmation d’applications (API) est le moyen par lequel un système accède au service d’un autre système. Dès que vous avez ouvert une interface à des acteurs extérieurs à votre organisation (partenaires, clients professionnels ou communauté de développeurs), vous avez créé un canal d’accès à vos données et à votre infrastructure. Le document qui encadre ce canal n’est pas une documentation technique, mais un contrat.

La conclusion du contrat n’a rien de particulier : l’offre et l’acceptation au sens de la loi sur les contrats (partie générale), 5733-1973 (חוק החוזים (חלק כללי), התשל״ג-1973) peuvent se former aussi par une validation électronique et par l’utilisation effective d’une clé d’accès. La particularité tient au contenu. Elle tient aussi au fait que, dans la plupart des cas, il s’agit d’un texte standard rédigé à l’avance par une seule partie.

Les conditions d’une API sont-elles un contrat d’adhésion ?

L’article 2 de la loi sur les contrats d’adhésion, 5743-1982, définit le « contrat d’adhésion » comme le texte d’un contrat dont les clauses, en tout ou en partie, ont été fixées à l’avance par une partie pour servir de conditions à de nombreux contrats entre elle et des personnes indéterminées quant à leur nombre ou à leur identité. Les conditions d’utilisation d’une interface publiées sur un site et applicables à toute personne qui s’inscrit répondent presque toujours à cette définition.

L’article 5 de la loi s’applique donc. Une clause qui exclut ou limite le droit du client de saisir les tribunaux est nulle. Une clause qui exonère le fournisseur de sa responsabilité pour un dommage corporel ou pour un acte intentionnel est nulle. S’y ajoutent les présomptions de caractère abusif de l’article 4. Parmi elles : l’exonération d’une responsabilité imposée par la loi ou sa limitation déraisonnable (alinéa 1), un droit déraisonnable d’annuler, de suspendre ou de modifier des obligations essentielles (alinéa 2), la modification unilatérale du prix après la conclusion (alinéa 4), la suppression d’un droit ou d’un recours dont le client dispose selon la loi (alinéa 6), une clause d’arbitrage (alinéas 8–10) et une dérogation aux règles légales de compétence territoriale (alinéa 9).

C’est pourquoi la clause « nous pouvons fermer l’accès à tout moment, pour tout motif, sans préavis » n’est pas une clause solide. Une rédaction qui tient la route distingue selon les motifs. Une violation de la politique d’utilisation ou un risque de sécurité justifient une suspension immédiate. Un changement commercial justifie un préavis d’une durée définie.

Définir l’usage permis, et l’usage interdit

C’est de cette clause que découlent la plupart des litiges. Ce qui n’a pas été interdit expressément est très difficile à interdire après coup :

• L’étendue de l’usage : à quelles fins les données peuvent être utilisées, et si elles peuvent être affichées aux utilisateurs finaux du développeur.
• Le produit concurrent : est-il permis de construire, au moyen de l’interface, un service qui concurrence l’exploitant ? Si ce n’est pas permis, il faut définir ce qu’est une concurrence.
• Le transfert à un tiers : est-il permis de transférer l’accès, de le vendre ou de l’intégrer dans un produit revendu ?
• L’extraction et l’accumulation : est-il permis de stocker les données de façon permanente et d’en constituer une base indépendante, ou seulement d’en faire un usage ponctuel ?
• Les limites de débit : le nombre d’appels par seconde, par minute et par jour, et la conséquence d’un dépassement (ralentissement, facturation supplémentaire ou blocage). Une limite qui n’a pas été fixée dans le contrat est difficile à faire respecter après coup.

Un point souvent oublié : la documentation technique elle-même. Dans la plupart des contrats, elle y est intégrée par renvoi (« sous réserve de la documentation publiée de temps à autre »). Elle devient ainsi une partie du contrat, avec toutes les conséquences que cela implique. Si vous adoptez une telle structure, conservez des versions datées de la documentation : en cas de litige, la question sera de savoir ce qui était exactement permis à la date pertinente. La même règle vaut pour les bibliothèques et les kits de développement. La licence qui s’y applique, et parfois aussi les licences open source qui y sont intégrées, s’ajoutent au cadre contractuel.

Disponibilité, versions et retrait d’une fonctionnalité

Un développeur qui a construit un produit entier sur une interface externe est exposé à deux risques : que l’interface tombe en panne, et qu’elle change. Le contrat doit traiter ces deux risques séparément. Pour la disponibilité : un objectif de disponibilité, la méthode de mesure, et un recours réel, pas seulement un avoir symbolique. Pour les changements : une politique de versions claire, un engagement sur une période minimale de maintenance d’une version existante, et un calendrier de préavis avant le retrait d’une fonctionnalité.

Le retrait soudain d’une fonctionnalité essentielle est exactement la situation où la présomption de caractère abusif de l’article 4(2) de la loi sur les contrats d’adhésion est pertinente : un droit déraisonnable du fournisseur de modifier des obligations essentielles du contrat. À l’inverse, l’exploitant qui a fixé à l’avance une politique de versions raisonnable, publié un calendrier et prévenu en conséquence se trouve dans une bien meilleure position.

Clés d’accès, usage abusif et loi sur l’informatique

Une clé d’accès est un moyen d’identification, et elle fuit souvent : elle est enregistrée dans du code open source, transmise entre salariés, ou volée. Le contrat doit prévoir expressément l’obligation de garder la clé confidentielle, l’interdiction de la partager, l’obligation de signaler immédiatement tout soupçon de fuite, et la responsabilité de l’usage fait au moyen de la clé jusqu’à la date du signalement.

Au-delà du contrat, un niveau pénal s’applique. L’article 4 de la loi sur l’informatique, 5755-1995 prévoit que quiconque s’introduit illégalement dans des données informatiques se trouvant dans un ordinateur est passible de trois ans d’emprisonnement. Selon l’article 5, une telle intrusion commise pour commettre une autre infraction est passible de cinq ans. L’article 2 interdit de perturber le fonctionnement normal d’un ordinateur ou d’entraver son utilisation. L’article 6(b) interdit de diffuser ou de transmettre un mot de passe ou un code d’accès afin que l’un des actes interdits soit commis. L’utilisation d’une interface au-delà de l’autorisation, ou la transmission d’une clé à un tiers pour qu’il en fasse un usage interdit, risquent de relever de ces articles.

Le lien entre ces niveaux est concret : plus l’autorisation est définie précisément dans le contrat, plus il est facile de montrer qu’un acte donné a été commis « illégalement » ou au-delà de l’autorisation.

Soupçon d’usage au-delà de l’autorisation ou de fuite de clé : que faire

1. Suspendez ou remplacez la clé, selon le mécanisme de suspension prévu au contrat.
2. Documentez l’événement : le responsable d’une base de données doit documenter tout événement qui fait craindre un usage des informations sans autorisation ou au-delà de l’autorisation (article 11(a) du règlement sur la sécurité des données).
3. Conservez les journaux d’accès. Pour une base de données de niveau de sécurité moyen ou élevé, ils sont conservés au moins 24 mois (article 10(d)).
4. Vérifiez s’il s’agit d’un « incident de sécurité grave » au sens de l’article 1. Si c’est le cas, informez-en immédiatement l’Autorité de protection de la vie privée (article 11(d)).
5. Envoyez au développeur une mise en demeure écrite de cesser l’utilisation et de supprimer les informations extraites, conformément au contrat.
6. Lorsque vous soupçonnez une intrusion illégale ou une perturbation, envisagez une plainte à la police au titre de la loi sur l’informatique (articles 2 et 4).

Les informations personnelles qui transitent par l’interface

Si des informations sur des personnes circulent par l’interface, le droit de la protection des données entre en jeu. La loi sur la protection de la vie privée, 5741-1981 (חוק הגנת הפרטיות, התשמ״א-1981), a été modifiée par l’amendement n° 13, entré en vigueur le 14 août 2025. Dans sa version actuelle, le responsable de la base de données est celui qui fixe les finalités du traitement, et le détenteur est un acteur extérieur qui traite des informations pour son compte. Dans une interface où le développeur traite des informations pour l’exploitant, le développeur est le détenteur. Dans une interface où l’exploitant fournit un service au développeur sur des informations des clients du développeur, la relation peut s’inverser. Fixer expressément les rôles dans le contrat évite un litige ultérieur.

Lorsque la relation implique de donner accès à une base de données, l’article 15 du règlement sur la sécurité des données, 5777-2017, impose de fixer dans le contrat plusieurs points. Il s’agit des informations qui peuvent être traitées et des finalités de l’usage, des systèmes accessibles, du type de traitement, de la durée de la relation et des modalités de restitution et de destruction des informations à son terme. S’y ajoutent les modalités d’application des obligations de sécurité, l’engagement de confidentialité des personnes autorisées, les règles de recours à un sous-traitant, et des obligations de rapport : au moins une fois par an, et une notification au responsable de la base de données en cas d’incident de sécurité. La même exigence s’applique à tout contrat de cloud ou de service.

Responsabilité : qui supporte le dommage, et envers qui

Dans une interface ouverte, il y a trois cercles de dommage, et chacun a son propre régime. Le premier cercle est le dommage que le développeur cause à l’exploitant : une surcharge qui fait tomber le service, un usage non autorisé des données ou une faille venant de son côté. Il faut ici un engagement d’indemnisation du développeur, défini dans son étendue et plafonné, accompagné d’un droit de suspension immédiate.

Le deuxième cercle est le dommage que l’exploitant cause au développeur : interruption de service, altération de données ou coupure soudaine. Une large exonération est généralement proposée ici, et c’est elle qui est examinée au regard de la loi sur les contrats d’adhésion. Une exonération générale relève de la présomption de caractère abusif de l’article 4(1). Une exonération de responsabilité pour un dommage corporel ou pour un acte intentionnel est nulle selon l’article 5(b). Un plafond proportionné, qui exclut expressément l’acte intentionnel, la violation de la confidentialité et la violation des obligations de sécurité des données, résiste beaucoup mieux.

Le troisième cercle est le dommage causé à un tiers : l’utilisateur final du développeur, touché par une panne ou par une fuite. Dans ce cas, les deux parties risquent d’être poursuivies ensemble, et la question interne est le partage de la responsabilité entre elles. Une clause de garantie d’indemnisation réciproque, qui répartit le risque selon l’origine de la défaillance et non selon l’identité du demandeur, évite un second procès. Il est utile aussi de prévoir un mécanisme de coopération dans la défense : qui conduit la procédure, qui supporte les coûts et qui est autorisé à transiger.

En outre, lorsque l’interface transmet des informations personnelles, il est utile d’exiger une assurance adaptée et de définir son étendue et sa durée de validité, y compris après la fin de la relation. Dans ce domaine, l’exposition se révèle souvent tardivement.

Propriété intellectuelle, données et réalisations

Trois questions de propriété distinctes, qu’il vaut mieux ne pas mélanger. La première : les droits sur l’interface elle-même, sur la documentation et sur les bibliothèques. Ils restent à l’exploitant, et le développeur reçoit une licence d’utilisation limitée, non exclusive et non transférable. La deuxième : les données transmises par l’interface. À qui appartiennent-elles, et que peut-on en faire après la fin de la relation ? La troisième : les réalisations que le développeur crée au-dessus de l’interface. Son application lui appartient, mais elle contient peut-être des composants qui proviennent de l’exploitant.

Une autre clause recommandée : l’usage du nom et des marques. Les développeurs ont tendance à afficher le nom de l’exploitant pour inspirer confiance, et les exploitants ont tendance à afficher leurs clients. Mieux vaut fixer à l’avance ce qui peut être affiché, dans quel contexte, et quand l’autorisation prend fin.

Résiliation, modification et préavis

Un contrat d’interface raisonnable distingue trois situations de fin. La résiliation à l’initiative du développeur. La résiliation à l’initiative de l’exploitant pour des raisons commerciales, qui exige un préavis raisonnable. Et la suspension immédiate en raison d’une violation, d’un risque de sécurité ou d’une demande d’une autorité. Pour chaque situation, il faut prévoir le sort des données déjà transmises : suppression, restitution, ou poursuite d’un usage limité.

Quant à la modification des conditions, la formule courante « la poursuite de l’utilisation vaut acceptation des conditions mises à jour » est examinée, dans un contrat d’adhésion, au regard des présomptions de caractère abusif. Une version équilibrée prévoit un préavis et distingue une modification technique d’une modification essentielle. Elle laisse aussi au développeur un délai pour mettre fin à la relation sans pénalité si la modification est essentielle.

Questions fréquentes

Les conditions d’utilisation d’une API engagent-elles si l’on a seulement coché une case ?

Oui, en règle générale. Le consentement peut se former par une validation électronique et par l’utilisation effective de la clé d’accès. Toutefois, lorsqu’il s’agit d’un texte standard rédigé à l’avance par la partie forte, certaines de ses clauses risquent d’être annulées ou modifiées au titre de la loi sur les contrats d’adhésion. Une clause qui exclut le droit de saisir les tribunaux est nulle dès l’origine.

Que se passe-t-il si un développeur dépasse les limites de débit ?

Si les limites et la conséquence d’un dépassement ont été fixées dans le contrat, la conséquence prévue s’applique : ralentissement, facturation supplémentaire ou suspension. Si elles n’ont pas été fixées, l’exploitant ne dispose que d’arguments généraux. Parfois, il peut aussi invoquer la loi sur l’informatique pour entrave à l’utilisation d’un ordinateur, un argument plus difficile à prouver.

Peut-on couper l’accès d’un développeur sans préavis ?

Cela dépend du motif et de la rédaction. Une suspension immédiate en raison d’une violation ou d’un risque de sécurité est raisonnable. Une coupure commerciale sans préavis, surtout lorsque le développeur a construit un produit sur l’interface, est examinée au regard de la présomption de caractère abusif de l’article 4(2) de la loi sur les contrats d’adhésion. Mieux vaut définir à l’avance les motifs et les délais de préavis.

Faut-il un accord distinct sur la vie privée pour l’interface ?

Si des informations sur des personnes y transitent, oui. Il faut déterminer qui est le responsable de la base de données et qui est le détenteur. Il faut aussi inclure les points énumérés à l’article 15 du règlement sur la sécurité des données : l’étendue du traitement, les systèmes, le type d’opérations, la durée de la relation, la restitution et la destruction des informations, l’application des obligations de sécurité, la confidentialité, les sous-traitants et le signalement d’un incident de sécurité.