Est-ce légal d'utiliser l'API interne d'un site ?

Ce sont les appels que votre navigateur passe déjà en affichant la page, donc rien n'est forcé. Le cadre reste le même que pour toute collecte : conditions d'utilisation du site, RGPD si des personnes sont identifiables, droit des bases de données.

Quelle différence avec une API publique ?

L'engagement. Une API publique est documentée et s'engage sur sa stabilité ; un appel interne peut changer sans préavis parce qu'il n'était destiné qu'au site lui-même.

Tous les sites en ont-ils une ?

Non. Les sites qui écrivent leurs données directement dans le HTML n'ont rien à intercepter, et il faut alors lire la page. C'est justement ce qui se vérifie avant de chiffrer.

Et si l'appel demande un jeton ?

C'est fréquent et souvent gérable en reproduisant la séquence d'obtention. Cela devient coûteux quand le site signe ses requêtes par un calcul propriétaire. C'est un des cas où nous recommandons une autre voie.

Trouver l'API interne d'un site web

Ce qui se passe quand une page se charge

Ouvrez une liste de produits ou d’annonces sur un site moderne. La page qui arrive d’abord est souvent presque vide : une structure, des styles, du code. Ce code passe ensuite un ou plusieurs appels en arrière-plan, et reçoit en retour les données sous une forme déjà organisée, généralement du JSON. C’est seulement à ce moment que les éléments s’affichent.

Autrement dit, quelque part entre le serveur et votre écran, la donnée existe déjà proprement rangée, avec ses champs nommés et ses types. La lire à ce moment-là, plutôt qu’après qu’elle ait été transformée en habillage visuel, évite de refaire le chemin à l’envers.

On parle souvent d’« API cachée ». Le terme est pratique mais trompeur : rien n’est caché, ces appels sont visibles dans n’importe quel navigateur par quiconque ouvre les outils de développement. Ils ne sont pas documentés, ce qui est différent. La nuance a des conséquences concrètes, détaillées plus bas.

Pourquoi c’est presque toujours mieux

Critère	Lecture du HTML	Appel interne
Format reçu	Habillage à décoder, champs mêlés à la mise en page	Données nommées et typées
Volume transféré	La page entière, styles et scripts compris	Les seules données utiles
Vitesse	Lente, surtout si un navigateur est nécessaire	Dix à cent fois plus rapide
Sensibilité au design	Une refonte graphique casse tout	Un changement visuel n’a aucun effet
Champs disponibles	Ce que la page affiche	Souvent plus que ce que la page affiche
Charge imposée au site	Forte	Réduite

Vos sites exposent-ils leurs données proprement ? Nous le vérifions systématiquement avant de chiffrer, parce que la réponse détermine le coût de tout le projet.

Demander un devis

Le dernier point compte davantage qu’il n’y paraît. Une collecte qui demande la page complète avec toutes ses ressources consomme les moyens du site visité. Passer par l’appel interne, c’est demander exactement ce dont on a besoin : plus efficace, et plus correct vis-à-vis de l’hébergeur.

Ce n'est pas un contournement

Ces appels sont ceux que votre navigateur passe lui-même en affichant la page. Les reproduire n’ouvre aucune porte fermée et ne donne accès à rien de plus que ce que le site vous montre déjà. Cela reste soumis aux conditions d’utilisation, comme toute collecte automatisée.

Comment on les trouve

Où regarder

Le repérage se fait dans le navigateur, en quatre gestes, et il ne demande aucun outil particulier.

Ouvrir les outils de développement, onglet Réseau. C’est le journal de tout ce que la page demande au serveur.
Activer le filtre Fetch/XHR. Les images, les styles et les polices disparaissent, il ne reste que les requêtes de données.
Recharger la page et repérer ce qui rapporte du JSON. Les appels intéressants se reconnaissent à leur réponse structurée plutôt qu’à leur adresse.
Rejouer l’appel isolément. C’est l’étape que l’on saute trop vite : un appel qui fonctionne dans le contexte de la page ne répond pas toujours seul. La faisabilité se joue là.

Comprendre les paramètres

La partie intéressante vient après. Un appel comporte presque toujours des éléments qui pilotent la pagination, les filtres, le tri, la langue ou la zone géographique. Les identifier permet d’obtenir exactement ce qu’on veut, parfois en une seule requête là où le site impose vingt clics.

Ce qu’on découvre souvent en chemin

Des champs invisibles à l’écran. Les réponses contiennent fréquemment plus que ce que l’interface affiche : identifiants internes, dates de mise à jour, indicateurs de stock.
Une limite de pagination généreuse. La page en montre vingt par défaut, l’appel en accepte parfois deux cents, ce qui divise d’autant le nombre de requêtes.
Un identifiant stable. Précieux pour suivre un même objet dans le temps, là où une adresse de page peut changer.

Les obstacles réels

Cette approche n’est pas toujours praticable, et il vaut mieux le savoir avant de promettre quoi que ce soit. C’est la partie que les tutoriels s’arrêtent juste avant d’écrire.

Les jetons et signatures

Beaucoup d’appels exigent un jeton obtenu au chargement de la page, parfois valable quelques minutes seulement. Il faut alors reproduire la séquence d’obtention. Certains sites vont plus loin et signent leurs requêtes avec un calcul effectué par leur propre code : dans ce cas, reproduire l’appel revient à réimplémenter ce calcul. L’exercice devient coûteux, et fragile.

L’absence totale de garantie

Une interface publique documentée s’engage sur sa stabilité et prévient de ses évolutions. Un appel interne n’est pas un contrat : il peut changer du jour au lendemain, sans annonce, parce qu’il n’était destiné qu’à l’usage du site lui-même. C’est la contrepartie directe de sa qualité, et la raison pour laquelle une collecte qui en dépend a besoin de contrôles de cohérence.

La pagination par curseur

Les appels modernes renvoient souvent un jeton de continuation plutôt qu’un numéro de page. On ne peut alors pas répartir le travail en parallèle sur des pages numérotées, il faut dérouler la séquence, ce qui limite la vitesse.

En pratique

Sur les projets où cette approche fonctionne, le coût d’infrastructure baisse dans des proportions qui changent la viabilité du projet : ni navigateur à faire tourner, ni volume transféré inutile. C’est la première chose à vérifier, avant même de parler de budget.

Questions fréquentes

Est-ce légal d'utiliser l'API interne d'un site ?: Ce sont les appels que votre navigateur passe déjà en affichant la page, donc rien n'est forcé. Le cadre reste le même que pour toute collecte : conditions d'utilisation du site, RGPD si des personnes sont identifiables, droit des bases de données.
Quelle différence avec une API publique ?: L'engagement. Une API publique est documentée et s'engage sur sa stabilité ; un appel interne peut changer sans préavis parce qu'il n'était destiné qu'au site lui-même.
Tous les sites en ont-ils une ?: Non. Les sites qui écrivent leurs données directement dans le HTML n'ont rien à intercepter, et il faut alors lire la page. C'est justement ce qui se vérifie avant de chiffrer.
Et si l'appel demande un jeton ?: C'est fréquent et souvent gérable en reproduisant la séquence d'obtention. Cela devient coûteux quand le site signe ses requêtes par un calcul propriétaire. C'est un des cas où nous recommandons une autre voie.

À lire ensuite