Infrastructure de recherche d'images pour agents IA : ce que le marché propose vraiment

Tous les frameworks d'agents sortis cette année savent écrire, planifier, appeler des outils et ouvrir une pull request. Demandez-en une photographie et tout s'effondre : une URL de banque d'images inventée de mémoire, un lien mort, ou une image générée parce que chercher une image réelle était plus compliqué que d'en fabriquer une. Les modèles ne sont pas le maillon faible. C'est la couche image qui les sous-tend — et elle manque d'une manière très précise, mesurable.

Ceci est une étude de marché, pas un manifeste. Tout ce qui suit a été mesuré ou lu depuis une source primaire le 18 août 2026 : un recensement du registre officiel MCP, les conditions publiées des quatre grandes API photo gratuites, les conditions d'accès des deux acteurs payants historiques ayant lancé des connecteurs pour agents ce mois-ci, et un petit benchmark reproductible que vous pouvez relancer en une minute sans clé API.

Une précision, pour que vous puissiez arrêter de lire tôt si ce n'est pas votre question : cet article porte sur la couche d'accès — récupération, accessibilité, conditions, quotas. Ce n'est pas le pipeline de publication. Si ce dont vous avez besoin, c'est comment transformer un brouillon en pages illustrées, créditées, balisées — le prompt de routage, les briefs visuels, l'assemblage, le balisage ImageObject — c'est traité séparément dans le pipeline qui illustre des articles rédigés par IA.

Ce qui change quand l'appelant est une machine

Un humain qui cherche une photo tape deux ou trois mots, parcourt une grille du regard, et sait reconnaître une bonne image quand il la voit. Tous les moteurs de recherche de banques d'images jamais construits reposent sur cette boucle. Un agent brise les trois hypothèses d'un coup :

1. Il écrit des phrases, pas des mots-clés. Un modèle qui vient de rédiger une section sur les papiers de crédit immobilier n'émet pas crédit ; il émet « une femme signant un document de crédit immobilier à une table de cuisine tandis qu'un conseiller bancaire explique les conditions ». C'est la production naturelle d'un modèle de langage, et c'est exactement ce qu'un index par correspondance de tokens ne peut pas servir.
2. Il ne peut pas parcourir une grille du regard. Ce que l'outil retourne est ce que l'agent connaît. Si la réponse est une liste d'URL sans description, dimensions ou crédit, l'agent doit récupérer et regarder chaque image — ou, bien plus souvent, deviner.
3. Il n'a pas de mains. Il ne peut pas téléverser des captures d'écran dans une file de révision, accepter des conditions, faire tourner une clé, ou attendre trois jours ouvrés pour une approbation de production. Chaque étape humaine dans l'intégration d'une API est un mur contre lequel l'agent s'arrête.

Ainsi, « infrastructure de recherche d'images pour les agents IA » n'est pas une formule marketing. C'est une liste de contrôle : recherche en langage naturel, résultats lisibles par machine assez riches pour raisonner, et un modèle d'authentification et de quota qu'un programme peut mener à bien seul.

Le test : une phrase contre un index à mots-clés

Le moyen le moins coûteux de constater le problème est d'envoyer les mots d'un agent tels quels à un moteur à mots-clés. Le test ci-dessous utilise Openverse, le moteur de recherche de médias sous licence libre géré par WordPress.org, parce que son API est publique, ne nécessite aucune clé, et que quiconque lisant ceci peut le relancer en moins d'une minute. Quatre briefs, du genre que rédige un modèle lorsqu'il illustre ce qu'il vient de rédiger :

import json, urllib.request, urllib.parse

BRIEFS = [
  "a woman signing a mortgage document at a kitchen table while a bank"
  " adviser explains the terms, warm morning light",
  "An elderly couple enjoying a peaceful retirement together",
  "a child discovering snow for the first time in a suburban garden",
  "a delivery cyclist waiting at a red light in heavy rain",
]

def count(q):
    u = "https://api.openverse.org/v1/images/?" + urllib.parse.urlencode({"q": q})
    r = urllib.request.Request(u, headers={"User-Agent": "benchmark/1.0"})
    return json.load(urllib.request.urlopen(r))["result_count"]

for b in BRIEFS:
    print(count(b), "|", b[:48])
# 0 | a woman signing a mortgage document at a kitchen
# 0 | An elderly couple enjoying a peaceful retirement
# 0 | a child discovering snow for the first time in a
# 0 | a delivery cyclist waiting at a red light in hea

Quatre briefs, quatre ensembles de résultats vides. Réduisez maintenant chaque brief aux deux mots-clés qu'un humain aurait tapés — signing document, elderly couple, child snow, cyclist rain — et chacun d'entre eux retourne une page complète de photographies (l'API en indique 240, c'est le plafond de comptage pour les appelants anonymes). Le catalogue contient bien les images. C'est la phrase qu'il ne peut pas analyser.

Faites glisser le tableau pour voir toutes les colonnes →

La colonne Pexafy correspond aux mêmes quatre phrases, envoyées sans modification à search_photos sur le serveur MCP hébergé, avec la latence renvoyée par le serveur lui-même. Il s'agit d'une comparaison de formes de requête, pas de qualité de catalogue — et le catalogue n'est très clairement pas le problème. Le propre point de statistiques d'Openverse indique 915 millions d'images issues de 52 sources le jour du test, et il excelle dans ce pour quoi il a été conçu : la recherche par mots-clés, pour des personnes. Rien n'est cassé. Il n'a simplement jamais été conçu pour un appelant qui pense en phrases. Pourquoi la correspondance par tags échoue face à une scène décrite — et ce que fait à la place la recherche sémantique — est développé côté lecteur dans chercher avec une phrase plutôt qu'avec des mots-clés ; ce qui est nouveau ici, c'est la mesure, et ce qu'elle signifie quand l'appelant est un programme plutôt qu'une personne.

« An elderly couple enjoying a peaceful retirement together » · 16 résultats en 135 ms · trois d'entre eux

Rang 1Pexels Pixabay Unsplash

Le marché, au 18 août 2026

La récupération n'est qu'une moitié du problème. L'autre moitié, c'est l'accessibilité : un agent peut-il seulement atteindre le catalogue, et à quelles conditions ? Depuis que le Model Context Protocol est devenu le moyen par lequel les assistants se connectent à des systèmes externes — sa spécification actuelle, datée du 28 juillet 2026, a fait passer le protocole vers un cœur requête/réponse sans état, ce qui permet aux serveurs de se placer derrière des répartiteurs de charge ordinaires1 — la manière honnête d'étudier ce marché est de regarder ce qui est réellement publié, pas ce qui est annoncé.

Les acteurs payants historiques sont arrivés ce mois-ci

Getty Images a lancé son serveur MCP le 12 août 2026, six jours avant cet article, en exposant la recherche et le téléchargement de contenu créatif, éditorial et d'archives aux workflows IA.2 Il s'adresse aux équipes d'entreprise et aux créateurs de plateformes, et sa propre page d'accès est sans ambiguïté sur le prix d'entrée : il faut un accord Getty Images actif, tel que Premium Access, ainsi que l'acceptation des conditions du Web Service. Il n'y a aucun palier gratuit. Le contenu Shutterstock est également accessible via un serveur MCP — 24 outils couvrant la recherche, les collections et les licences — avec des téléchargements verrouillés derrière un compte disposant d'un abonnement actif.3

Les deux démarches sont rationnelles et s'adressent chacune à un acheteur précis. Getty a enregistré 981,3 millions de dollars de chiffre d'affaires en 20254 sur un marché de la photographie de banque d'images estimé à environ 5,4 milliards de dollars pour 20265 ; des connecteurs exigeant un contrat protègent ce chiffre d'affaires plutôt que de l'ouvrir. Si vous êtes une banque ou un diffuseur, c'est exactement ce que vous voulez. Si vous êtes un développeur bricolant un projet personnel — ou un agent qui ne doit pas s'arrêter pour demander à un humain de signer quelque chose — c'est une porte fermée.

Les bibliothèques gratuites n'en ont sorti aucun

Unsplash, Pexels et Pixabay sont les trois catalogues vers lesquels se tournent le plus les développeurs, et aucun d'eux ne publie de serveur MCP officiel. Ce qui existe à la place, c'est une étagère de wrappers communautaires. Nous avons parcouru le registre officiel MCP en intégralité — 22 607 serveurs, 75 487 versions publiées — et conservé chaque entrée dont le nom ou la description concerne la recherche de photos ou de banques d'images. Le schéma est uniforme :

Faites glisser le tableau pour voir toutes les colonnes →

import json, urllib.request, urllib.parse

def crawl(term):                      # le registre pagine avec `nextCursor`
    out, cursor = {}, None
    while True:
        p = {"limit": "100", "search": term} | ({"cursor": cursor} if cursor else {})
        d = json.load(urllib.request.urlopen(
            "https://registry.modelcontextprotocol.io/v0/servers?" + urllib.parse.urlencode(p)))
        for e in d["servers"]: out[e["server"]["name"]] = e["server"]
        cursor = (d.get("metadata") or {}).get("nextCursor")
        if not cursor or not d["servers"]: return out

servers = {}
for t in ["photo", "image", "stock", "picture", "unsplash",
          "pexels", "pixabay", "getty", "shutterstock", "openverse"]:
    servers |= crawl(t)

# 137 serveurs uniques · distant vs local se lit dans `server["remotes"]`
# les clés tierces requises sont dans packages[].environmentVariables

Chacun de ces wrappers est un client léger des trois mêmes API à mots-clés, ce qui signifie que le benchmark ci-dessus s'applique à tous : le transport a changé, la récupération non. Un wrapper ne peut pas faire comprendre une phrase à un index de tags.

La clause qui arrête une machine n'est pas le quota

Les quotas et conditions des bibliothèques gratuites sont comparés côte à côte, dans une unité commune, dans la comparaison des API photo gratuites — les files d'approbation, l'appel de téléchargement obligatoire, l'obligation de mise en cache de 24 heures, les règles d'attribution. Cet article les lit du point de vue d'un développeur choisissant un fournisseur. Relisez-les cette fois du point de vue du programme qui doit s'y soumettre, et une ligne se détache qui n'a rien à voir avec le volume :

La même lecture s'applique à l'intégration. Un palier de démonstration qui ne devient production qu'après qu'un humain a examiné des captures d'écran de votre application n'est pas une limite de débit dont un agent peut se dégager ; c'est une étape qu'il ne peut tout simplement pas franchir. Pixabay énonce explicitement son intention — l'API est destinée à un usage humain légitime, et le téléchargement automatisé massif est interdit. Rien de tout cela n'est déraisonnable : les photographes offrent leur travail et quelqu'un paie pour la bande passante. Cela décrit simplement une API dont l'appelant supposé disposait d'un écran et d'une paire de mains.

Quatre exigences, et qui les remplit

En réunissant les deux moitiés, la spécification d'une couche image qu'un agent peut réellement utiliser se révèle courte et testable. Ce n'est délibérément pas une comparaison de fournisseurs — taille de catalogue, tarification et conditions de licence sont alignées dans l'article de comparaison. Ces quatre points ne portent que sur la capacité d'un programme à atteindre les images :

1. Recherche sémantique — une phrase complète retourne une page classée, pas un ensemble vide.
2. Licences gratuites, plusieurs sources — rien à licencier par image, et aucune bibliothèque unique dont le goût définirait toutes les pages que vous publiez.
3. Un serveur hébergé avec sa propre connexion — distant, OAuth, aucun processus local à installer et aucune clé API tierce à coller dans un fichier de configuration.
4. Un palier gratuit qu'une machine peut mener à bien seule — pas d'examen de captures d'écran, pas de contrat, un quota mensuel et une limite de débit par minute qu'un worker peut gérer par lui-même.

Faites glisser le tableau pour voir toutes les colonnes →

Nous développons Pexafy, lisez donc cette dernière ligne avec le scepticisme qu'elle mérite — puis vérifiez-la : le recensement du registre est reproductible en un script, les conditions d'accès à Getty et Shutterstock figurent sur leurs propres pages, et les limites des trois API photo sont dans leur propre documentation, toutes liées en bas de page. L'affirmation est étroite et falsifiable : au 18 août 2026, nous n'avons pas trouvé de deuxième service réunissant les quatre points. Si vous en connaissez un, nous l'ajouterons à ce tableau — l'intérêt de mettre par écrit ces exigences, c'est que n'importe qui peut les appliquer à n'importe quel produit, le nôtre compris.

Ce que fait un bon serveur d'images via MCP

Un connecteur n'est pas un endpoint REST repeint. Deux usages de cette couche sont traités ailleurs et ne sont pas répétés ici — illustrer un brouillon, dans l'article sur le pipeline, et garder une longue série visuellement cohérente, dans celui sur le volume. Ce qui relève de l'infrastructure, c'est ce dont les deux dépendent et que ni l'un ni l'autre ne peut ajouter après coup : trois décisions côté serveur, prises une fois, pour chaque agent qui se connecte.

1. Retourner des objets sur lesquels un agent peut raisonner. Ce que retourne l'outil est tout ce que connaît le modèle — il ne peut pas parcourir une grille du regard. La différence entre les deux formes ci-dessous, c'est la différence entre un assistant qui raisonne sur des photographies et un assistant qui relaie de simples liens :

# Wrapper à mots-clés typique : l'agent doit récupérer et regarder, ou deviner
[{ "url": "https://…/photo-8795398.jpeg" }, { "url": "https://…/366611.jpg" }]

# Un résultat, tel que retourné — tronqué ici, rien ajouté
{
  "rank": 1,                       // le repère qu'utilise un humain : « plus comme #1 »
  "photo_id": "019e14d9-e821-…",   // ce que prend get_similar_photos
  "width": 6424, "height": 4283, "orientation": "landscape",
  "color_hex": "#918872", "blur_hash": "LPI#Px?aDikCGwW?M{kD-VR*s.fl",
  "source": "Pexels", "license_type": "free",
  "alt_description": "Older couple sits together on wooden bench in a park",
  "attribution": { "plain": "Photo by Anastasia Shuraeva on Pexels", "html": "…" },
  "urls": { "thumb": "…", "small": "…", "regular": "…", "large": "…" }
}

Avec la seconde forme, un agent peut dire « #3 est en portrait, ça va casser votre emplacement principal », écarter un photographe déjà utilisé, produire la mention de crédit, et fournir à votre template une paire width/height qui élimine le décalage de mise en page — sans récupérer une seule image. Avec la première, chacune de ces décisions est une supposition ou un aller-retour.

2. Numéroter les résultats, pour qu'une personne puisse les désigner. Les résultats reviennent classés #1, #2, #3…, ce qui correspond à la façon dont n'importe qui désigne une photo en conversation — « plus comme #3 » — sans identifiant à copier à la main. Dans les clients compatibles avec MCP Apps, les vignettes s'affichent en ligne, et en ouvrir une révèle des métadonnées déjà présentes dans le résultat de l'outil, sans appel supplémentaire.

3. Rester en lecture seule, et l'assumer explicitement. Trois outils, aucune portée d'écriture, aucune modification de compte. L'un de ces outils n'a aucun équivalent à mots-clés nulle part : search_photos_by_image prend une image de référence — la photo principale existante d'un client, une capture d'écran collée dans la conversation — plus une phrase optionnelle pour l'infléchir (« comme ceci, mais de nuit »). Aucun champ dans une API à correspondance de tags ne permet même de saisir une telle requête. Et un agent qui ne peut rien modifier a comme pire résultat possible un ensemble vide, plutôt qu'un ticket de support.

Les deux surfaces, et celle qu'il vous faut

Il existe exactement deux voies d'accès, et le choix porte sur qui est dans la boucle plutôt que sur la capacité — les outils et le catalogue sont identiques sur les deux.

Le connecteur, quand une personne est dans la boucle. Une seule URL, https://mcp.pexafy.com/mcp, ajoutée une fois dans les réglages de connecteurs d'un assistant ; la connexion se fait dans une fenêtre de navigateur et le client reçoit ses propres identifiants, donc il n'y a aucune clé à coller dans un fichier de configuration ni à faire tourner ensuite. Les clients qui n'implémentent pas OAuth envoient une clé API Pexafy comme jeton porteur sur le même endpoint — ce qui rend le connecteur utilisable depuis une tâche cron sur un serveur de build, où personne n'est présent pour cliquer sur « Autoriser ». Le câblage étape par étape pour Claude, ChatGPT et un fichier de configuration de flotte figure dans l'article sur le pipeline ; il n'a pas changé.

L'API HTTP, quand personne n'y est. Un job batch remplissant un pool pour 800 clusters de sujets ne devrait pas se faire passer pour un client de chat : même compte, même clé, HTTP brut, 100 résultats par appel. Les règles de cadence qui l'accompagnent — les en-têtes de limite de débit, pourquoi une erreur 429 par minute mérite d'être retentée alors qu'une erreur 429 de quota mensuel ne le mérite pas, ce que coûte un worker à volume — relèvent de l'article sur l'illustration à grande échelle, où ce worker est détaillé intégralement.

Le point à retenir ici est plus étroit, et c'est celui sur lequel repose l'étude de marché : les deux surfaces sont accessibles à un programme le jour même où il est écrit, sans file d'attente et sans contrat.

Ce que cela ne résout pas

Une liste honnête, car chacun de ces points a déjà coûté un rollback à quelqu'un.

• La licence continue de régir l'image. L'attribution n'est pas exigée par les conditions de l'API Pexafy et chaque résultat fournit une chaîne d'attribution prête à afficher — mais la licence attachée par la bibliothèque d'origine s'applique à votre usage de cette photo. Affichez le crédit automatiquement ; c'est moins coûteux qu'un audit ultérieur.
• Les catalogues sous licence gratuite ne sont pas des archives éditoriales. Ni actualité, ni sport, ni marques reconnaissables ou personnalités publiques à la demande. Si votre page a besoin d'une photographie d'un événement ou d'une personne précise, c'est le rôle des acteurs sous licence, et leurs connecteurs existent désormais.
• C'est de la récupération, et seulement de la récupération. Les diagrammes, graphiques et captures d'écran sont générés à partir de code, pas recherchés ; la déduplication entre vos pages est une colonne de votre base de données, pas un paramètre de l'endpoint ; et aucune photographie ne fait grimper le classement d'une page pauvre en contenu — les politiques anti-spam de Google traitent l'abus de contenu à grande échelle de la même façon, que les pages soient illustrées ou non.6 Ces trois points sont des problèmes de pipeline avec des réponses de pipeline, développés dans l'article sur le pipeline et celui sur le volume.

Par où commencer

1. Relancez le benchmark. Vingt lignes, sans clé. Quelle que soit l'API image que vous utilisez aujourd'hui, envoyez-lui trois briefs de votre propre agent tels quels et comptez les ensembles de résultats vides.
2. Ajoutez un connecteur à l'assistant que vous utilisez déjà et demandez-lui, en une phrase, une photo dont vous avez réellement besoin cette semaine. C'est toute l'évaluation.
3. Déplacez les briefs dans l'agent — une scène par emplacement, écrite à partir du brouillon, jamais du titre.
4. Ajoutez la colonne photo_id avant de publier quoi que ce soit à volume.
5. Faites-le fonctionner sur le palier gratuit — 5,000 recherches par mois à 20 par minute jusqu'à ce qu'une fenêtre de build, et non une facture, vous pousse à monter en gamme.

Références & notes