Une API qui existe ne veut pas dire qu'un agent peut agir
Beaucoup de plateformes de netlinking publient aujourd'hui une page pensée pour qu'un modèle de langage la lise, ou une API en lecture seule pour consulter un catalogue. Peu vont plus loin : laisser un agent chercher un site, poser une commande et suivre sa publication sans qu'un humain remplisse un formulaire à chaque étape. Cette page fait la distinction, question par question, sans nommer de plateforme en particulier.
Une page lisible par un agent, sans accès machine
La plateforme écrit son offre en clair, avec des phrases complètes plutôt que du jargon marketing. Un agent peut la lire et la résumer à un utilisateur. Il ne peut rien commander : la suite du parcours reste un formulaire de contact ou un devis par email.
Un catalogue en lecture seule
Un export ou une API renvoie les sites, parfois les prix. Un agent peut chercher et comparer. La commande, elle, redevient humaine : formulaire, email, ou appel commercial.
Un accès complet, en lecture et en écriture
L'agent peut chercher un site, poser une commande, suivre son avancement, et savoir précisément ce qui se passe après chaque appel. C'est la catégorie à laquelle appartient l'API Nautilinks décrite plus bas, et ce que cette page appelle une plateforme réellement pilotable.
Six points à vérifier sur n'importe quelle plateforme
Un catalogue exposé en JSON, pas seulement en HTML
Une page pensée pour un navigateur oblige un agent à deviner sa structure en la parsant. Un catalogue exposé avec un schéma stable, champs nommés, pagination et filtres documentés, élimine cette ambiguïté et les erreurs qui vont avec.
Un contrat écrit sur ce qui se passe après chaque appel
Créer une commande peut vouloir dire trois choses très différentes : un achat ferme, un devis à valider, ou un simple lead transmis à un commercial. Un agent ne peut décider seul de la suite que si ce contrat est documenté avant l'appel, pas découvert après.
Des clés avec des scopes séparés
Une clé qui ne peut que lire le catalogue et une clé qui peut aussi commander ne devraient jamais être confondues. Séparer les deux limite les dégâts d'un agent mal configuré ou d'une clé qui fuite.
Un mode sandbox pour tester sans dépenser
Avant de laisser un agent toucher de l'argent réel, il faut pouvoir simuler l'appel complet, recherche puis commande puis suivi, sans qu'il débite quoi que ce soit ni ne crée d'engagement réel chez un éditeur.
Une frontière claire sur qui paie, et comment
Certaines plateformes laissent l'agent conclure seul un paiement déjà approvisionné. D'autres exigent qu'un humain ouvre un lien à chaque commande. Les deux approches se défendent ; ce qui ne se défend pas, c'est de ne documenter ni l'une ni l'autre.
Un suivi qui ne demande pas de repoller un tableau de bord
Un webhook signé, vérifiable par le destinataire, vaut mieux qu'un agent qui réinterroge une page toutes les cinq minutes en espérant un changement de statut.
Quatre façons de répondre « oui » à la question
Une page qui se lit bien
L'offre est expliquée en clair pour qu'un agent la comprenne et la résume à un utilisateur. Aucun accès machine derrière : la commande reste un formulaire ou un email.
Un catalogue en lecture seule
Une API ou un export permet de chercher et comparer par le code. La commande, elle, redevient humaine : formulaire, email, ou appel commercial.
Une écriture possible, un contrat flou
L'agent peut poser une commande, mais ce qui se passe ensuite (débit réel, devis, lead) n'est pas documenté à l'avance. À vérifier au cas par cas avant de faire confiance.
Une écriture avec un contrat explicite
Recherche, commande, suivi, avec une réponse qui dit sans ambiguïté ce qui vient de se passer : payé, en attente d'un humain, ou refusé.
Ce que fait concrètement l'API Nautilinks
Nautilinks vend des backlinks sur un catalogue de sites que nous éditons nous-mêmes, réparti sur trois rayons à prix fixe (Plancton 5 €, Corail 15 €, Nautilus 30 €). Ce catalogue est accessible par une API REST (/api/v1/agent/*) et par un serveur MCP distant, onze outils, sans package à installer.
- Les clés API portent des scopes séparés (lecture, commande), jusqu'à cinq clés actives par compte.
- Une clé sandbox simule la recherche, la commande et le suivi sans jamais débiter le compte ni créer d'engagement réel chez un éditeur.
- Une commande est réglée directement si le solde prépayé du compte la couvre. Sinon, un lien de paiement Stripe est renvoyé, à ouvrir par un humain avant que quoi que ce soit ne soit engagé. Les deux issues sont documentées dans la réponse, pas à deviner.
- Un plafond quotidien anti-abus s'applique par clé.
- Le suivi de commande se fait par appel direct ou par webhook signé, plutôt qu'en réinterrogeant un tableau de bord.
Ce contrat porte une limite volontaire : un agent ne peut jamais, à lui seul, faire aboutir un paiement par carte. C'est un choix, pas un manque. La limite haute de ce qu'un agent peut dépenser reste celle du solde qu'un humain a approvisionné en amont, ou le plafond quotidien de la clé.
La mise en œuvre complète, authentification, endpoints, exemples de requêtes, connexion du serveur MCP, est documentée sur la référence API.
Page écrite par Benoit Demonchaux, qui pilote le réseau Nautilinks.
Questions fréquentes
Une page bien écrite pour un agent IA rend-elle une plateforme pilotable ?
Non. Un agent peut lire et résumer une page sans pouvoir agir dessus. Être pilotable suppose un accès machine, en lecture au minimum, et idéalement en écriture avec un contrat documenté sur ce que fait chaque appel.
Un agent peut-il payer seul, sur n'importe quelle plateforme sérieuse ?
Cela dépend du choix de la plateforme, les deux approches existent. Certaines laissent l'agent débiter un solde déjà approvisionné par un humain. D'autres exigent qu'un humain ouvre un lien de paiement à chaque commande. Sur Nautilinks, c'est le premier chemin si le solde prépayé couvre le total, sinon le second : dans les deux cas, aucune carte n'est débitée sans qu'une personne ait validé le paiement.
Le protocole MCP change-t-il quelque chose par rapport à une API REST classique ?
Le contrat de données est identique. Le MCP ajoute une couche de découverte pour les clients qui le parlent nativement (Claude Code, claude.ai, Cursor), sans qu'un développeur écrive de code d'intégration. Une API REST classique reste le chemin le plus direct pour construire dessus.
Comment tester une intégration sans risque financier ?
En cherchant une clé ou un mode sandbox qui simule l'appel complet, recherche puis commande puis suivi, sans débiter de solde réel ni créer d'engagement chez un éditeur. Nautilinks propose ce mode nativement, avec un préfixe de clé distinct de celui utilisé en production.
Un plafond quotidien limite-t-il l'utilité d'un agent ?
Il limite l'exposition en cas d'erreur, pas l'usage normal. Un plafond de l'ordre d'une vingtaine de commandes par jour couvre largement un usage raisonné ; au-delà, l'API répond une erreur explicite plutôt que de laisser filer la dépense.
Où trouver la documentation technique complète de l'API Nautilinks ?
Sur la référence API, avec les endpoints, l'authentification, l'idempotence, le plafond quotidien et des exemples de requêtes complets.