Agents IA et API fermées : cas Dodo Pizza

Comment les agents IA redéfinissent les API commerciales : une étude de cas sur l’intégration avec Dodo Pizza sans interface ouverte

Le système est conçu comme une compétence extensible pour les frameworks d’agents (Claude Code, Kimiclaw, Openclaw), compatible avec toute interface prenant en charge des outils externes. Contrairement aux assistants vocaux, limités aux requêtes d’information, cet agent effectue des opérations étatiques : gestion du panier, sélection d’un point de retrait, authentification à deux facteurs via des cookies enregistrés et confirmation du paiement avant débit des fonds.

Un principe crucial est la séparation des responsabilités :

• Interface de l’agent — une interface claire en langage naturel : « commander une pizza à la saucisse avec une limonade », « afficher l’historique des trois dernières commandes » ;
• Logique d’exécution — un script Node.js (dodo.mjs) déclenché par le lanceur d’agents ;
• Interaction réseau — exclusivement via Chromium headless (Puppeteer), imitant le comportement d’un utilisateur réel.

L’agent ne parse HTML — il effectue des requêtes fetch() vers l’API interne du site depuis le contexte de la page chargée après avoir passé toutes les vérifications côté client. Pour le serveur, il apparaît comme un trafic utilisateur normal : même User-Agent, mêmes cookies, même navigator.webdriver === false, même ordre de chargement des ressources.

Ingénierie inverse de l’API fermée et lutte contre la détection

La documentation de plus de 30 endpoints a été obtenue en sniffant le trafic réseau via le Chrome DevTools Protocol. Le script intercepte toutes les requêtes fetch et XHR contenant /api/ lors d’une session utilisateur complète — de la consultation du menu jusqu’à la finalisation de la commande. Cela a fourni une carte complète des endpoints : GET /api/v5/menu, POST /api/v5/cart/add, PUT /api/v5/order/confirm, GET /api/v5/profile/bonuses, et bien d’autres.

Les principaux obstacles techniques et leurs solutions :

• Détection de Webdriver : ServicePipe vérifie navigator.webdriver. Solution : une ligne dans les options de lancement de Puppeteer — --disable-blink-features=AutomationControlled — plus une substitution manuelle des propriétés à l’exécution.
• Challenge JS : le site affiche une tâche captcha immédiatement après page.goto(). L’agent attend que le mot « livraison » apparaisse dans le <title> — indicateur d’un chargement SPA réussi.
• reCAPTCHA v3 lors de la connexion : aucune solution logicielle n’existe. L’autorisation est effectuée manuellement une fois sur une machine avec interface graphique ; les cookies sont sauvegardés dans un fichier et transférés au serveur. Durée de vie : 30 jours ; aucune rotation automatique n’est mise en place.
• Empreinte Canvas/WebGL : pas encore activée, mais l’architecture permet une intégration future avec puppeteer-extra-plugin-stealth.

Toutes ces mesures garantissent un fonctionnement stable pendant quatre mois sans défaillance ni blocage.

De la compétence à l’économie des agents : authentification sécurisée et orchestration inter-services

Actuellement, l’agent fonctionne selon un modèle « un utilisateur — un compte — un service ». Cependant, un modèle évolutif nécessite une identification standardisée des agents. Il est proposé d’utiliser les fournisseurs de télécommunications comme fournisseurs d’identité : MTS ID, Sber ID ou Tinkoff ID vérifient déjà l’identité via passeport et carte SIM. Le schéma de jeton d’agent de type OAuth :

• L’utilisateur s’authentifie une seule fois via le fournisseur de télécommunications ;
• Le fournisseur émet un JWT avec des scopes explicites : orders:dodo:read, orders:dodo:write, limit:2000rub/day ;
• Dodo vérifie la signature du jeton et valide le scope avant d’exécuter l’opération ;
• La révocation d’accès est instantanée via l’application mobile du fournisseur.

Cela élimine le besoin de stocker des cookies et d’effectuer une autorisation manuelle, donnant aux entreprises le contrôle sur les permissions et l’analytique.

Encore plus prometteur est le modèle de maître-agent. Il coordonne plusieurs compétences simultanément :

Maître Agent :
├── Compétence Dodo → Saucisse piquante 25 cm — 369₽ (retrait en 15 min)
├── Compétence Magnit → Bonne cola 1,5L — 89₽ (livraison en 30 min)
└── Conclusion : « Retire la pizza chez Dodo, commande la cola chez Magnit.
   Économise 66₽, obtiens trois fois plus de volume de cola. D’accord ? »

Un tel agent utilise le protocole A2A (Agent-to-Agent) : chaque service publie une description lisible par machine de ses capacités (par exemple, au format OpenAPI 3.1 avec l’extension x-agent-capabilities). Les agents se découvrent dynamiquement, sans intégration manuelle.

Ce qui compte

• Les agents sont déjà en production : l’auteur de la commande les utilise comme moyen principal de passer des commandes depuis décembre 2025 — ce n’est pas un PoC, c’est une solution opérationnelle.
• Les APIs fermées peuvent être utilisées légalement via un navigateur headless si le comportement d’un utilisateur réel est imité et que les Conditions d’utilisation ne sont pas violées (automatisation de ses propres actions sur son propre compte).
• Les entreprises perdent le contrôle et l’analytique quand elles ignorent le trafic des agents : les intégrations actuelles sont indiscernables des scrapers dans les métriques.
• Une API dédiée prête à l’emploi pour les agents n’est pas une option — c’est un avantage concurrentiel : elle réduit le CAC à zéro, élimine les commissions des places de marché et ouvre un canal pour des promotions personnalisées.
• La personnalisation devrait résider côté client : l’agent connaît l’historique des commandes, le budget et les préférences — les entreprises n’ont qu’à fournir une API propre et documentée.

Mise en œuvre : 380 lignes de JavaScript, une seule dépendance (puppeteer-core), installation en une seule commande. Le code n’est pas publié en open source pour des raisons éthiques : contourner les mesures anti-bot d’un service spécifique nécessite l’accord du propriétaire de l’API. L’objectif de cet article n’est pas de donner des instructions sur la contournement, mais d’inviter au dialogue sur la standardisation des interfaces des agents.

— Editorial Team