Réécrire, exécuter en JS ou tolérer un pont navigateur : l’échelle à trois niveaux pour intégrer du code rétro-ingéniéré

Comprendre ce que calcule un code rétro-ingéniéré ne suffit pas à le livrer. Après le découpage mécanique, l’identification de la famille algorithmique et la vérification différentielle, la logique reste prisonnière de son runtime d’origine. Il faut alors choisir sa forme finale : une fonction pure intégrable à la CI, ou un processus externe qu’il faudra surveiller. Un mauvais choix annule rapidement les gains obtenus en amont, et les intérêts se paient en production.

La vue d’ensemble en quatre étapes résume cela en une ligne : « Étape 4 : dégrader par couche de transport. » Ici, on développe le sujet. L’idée centrale tient en une phrase : à chaque niveau inférieur, la surface de dépendances, les modes de défaillance et le coût de déploiement augmentent d’un ordre de grandeur ; par défaut, il faut donc se battre pour remonter.

Trois formes de livraison, dans un ordre non négociable

Il n’existe que trois façons d’intégrer cette logique. Cet ordre, du meilleur au moins souhaitable, doit figurer dans vos conventions ; il ne doit pas être décidé au cas par cas selon « ce qui marche le plus vite » :

Réécriture native. Réécrivez dans votre langage cible, sans dépendre du runtime d’origine et en vous limitant à la bibliothèque standard. Cela suppose d’avoir correctement identifié la famille algorithmique : une fois l’étape de fingerprinting validée, 90 % du code provient de l’implémentation publique, les écarts restants sont traités séparément, et le résultat devient une fonction pure.
Moteur JS local et fragment minimal. Certaines logiques coûtent trop cher à purifier à court terme. Conservez alors une petite portion du JavaScript d’origine et exécutez les quelques dizaines de lignes nécessaires dans un Node/V8 local, jamais la page entière.
Pont navigateur passif. Certains états n’existent que dans le runtime réel d’une page ouverte et connectée : une signature fournie au runtime, un identifiant dynamique lié à la session. La reconstruction statique ne peut pas les reproduire ; pour l’instant, on peut uniquement les lire dans le navigateur. C’est une solution temporaire, qui doit être signalée dans les notes d’interface et ne doit jamais devenir le choix par défaut.

Pourquoi chaque niveau coûte beaucoup plus cher

Si cet ordre est fixe, ce n’est pas par principe : les coûts des trois niveaux ne progressent pas linéairement. Chaque niveau coûte un ordre de grandeur de plus que le précédent.

Niveau	Surface de dépendances	Mode de défaillance	Compatible CI ?
Réécriture native	Bibliothèque standard, aucun processus externe	Écart de sortie, localisé par un `assert`	Oui : c’est une fonction pure
Moteur JS local	Un runtime Node supplémentaire ; le contexte V8 n’est pas thread-safe, la concurrence exige un verrou	Version du moteur, globale attendue par le fragment mais absente	À peine : il faut installer le moteur
Pont navigateur passif	Un vrai Chrome + une extension + une session maintenue par un humain + un canal loopback local	Page fermée, session expirée, structure modifiée, onglet fermé	Non : il faut un humain actif

Au premier niveau, un test unitaire détecte les erreurs. Au troisième, l’erreur devient : « l’utilisateur a fermé cet onglet aujourd’hui ». Transformer une logique qui pourrait être une fonction pure en composant de troisième niveau attache un humain à chaque appel. À titre de repère, une fois la famille algorithmique identifiée, un SDK de signature obfusqué peut devenir une implémentation autonome de moins de 600 lignes, ne dépendant que de crypto intégré et fonctionnant au premier niveau. Ce que vous pensez devoir faire passer par un pont navigateur n’est généralement qu’un algorithme que vous n’avez pas encore complètement identifié.

Le pont passif : un instantané, jamais une action

Un pont navigateur passif ne dérape que d’une façon : lorsqu’il commence à « aider » en actualisant, en se connectant ou en attendant automatiquement le chargement. Chaque automatisme le fait glisser d’un simple relais vers un crawler. Sa frontière doit donc être extrêmement étroite. Ces contraintes ont été acquises à la dure :

Un seul relevé instantané, sans jamais modifier la page. Inspectez une seule fois les cookies, l’état de session et le runtime d’une page déjà ouverte. Ne créez pas d’onglet, n’actualisez pas, ne naviguez pas, ne donnez pas le focus, n’attendez pas en boucle. Une page absente est une page absente : ne l’ouvrez pas à la place de l’utilisateur.

Renvoyer une erreur explicite dès qu’un élément manque. En l’absence d’onglet correspondant, renvoyez tab_unavailable ; si la page est ouverte mais non connectée, not_logged_in ; si l’utilisateur est connecté mais que le runtime n’est pas prêt, runtime_unavailable. Ces trois codes correspondent chacun à un état réel et à une action suivante : attendre la page, se connecter ou changer de cible. Le demandeur n’a pas à deviner ce que cache un vague « échec ».

L’état sensible ne sort jamais du navigateur. L’extension ne demande aucune permission cookies / webRequest. Elle interroge uniquement un onglet correspondant déjà ouvert, exécute la demande dans le contexte de cette page, puis nettoie les champs avant le retour. Les cookies et l’état de signature de la page ne quittent pas Chrome, pas même une étape ; par défaut, le canal se connecte à une adresse loopback locale. Le pont transporte des résultats, jamais des identifiants.

Pourquoi 15 scopes ne couvrent que quelques plateformes

Le pont passif relaie des requêtes mises sur liste blanche : chemin, paramètres et referer sont tous contraints par un adaptateur. Le niveau de granularité peut surprendre : on compte 15 scopes pour seulement quelques plateformes, car les scopes sont découpés selon le « contexte de page », pas selon la « plateforme ». TikTok, par exemple, comprend Creative Center, Top Ads, Creator platform, la bibliothèque d’influenceurs et Ads Manager : cinq scopes distincts, donc cinq états de session et cinq runtimes de page distincts. Être connecté au back-office publicitaire ne donne pas accès au runtime de Creator platform. Un seul découpage par plateforme suffit pour que le premier cas « connecté au sous-site A, mais impossible de servir le sous-site B » vous ramène à la case départ. Xiaohongshu compte de la même manière trois scopes : son site principal, ses chemins équivalents à l’application et sa place de marché pour créateurs.

La granularité de l’ordonnancement suit cette logique : le verrou s’applique uniquement au niveau de la famille de plateformes. Les requêtes d’une même famille, celle de Douyin par exemple, s’exécutent en série : elles réutilisent le même véritable onglet, et des appels simultanés dans un même contexte de page se marcheraient dessus. En revanche, deux familles différentes, comme Douyin et Xiaohongshu, tournent en parallèle puisqu’elles correspondent à deux onglets sans rapport. Au sein d’une famille, ajoutez aussi un intervalle minimal entre les requêtes. Trop large, le verrou sérialise du travail parallélisable ; trop fin, les requêtes qui partagent un onglet entrent en collision. La famille de plateformes est précisément la frontière naturelle de ce qui « partage le même runtime de page ».

Relais de connexion explicite : la seule intervention humaine admise

Le pont passif ne pilote pas la page, mais les sessions expirent. La réponse consiste à concentrer l’intervention humaine dans une action explicite et ponctuelle : une commande interactive lance un relais, le programme ouvre la page métier concernée via le système d’exploitation, attend que vous vous connectiez manuellement et que la page soit prête, puis rejoue la requête initiale. L’extension ne clique sur aucun bouton, ne remplit aucun formulaire et n’exporte aucun cookie. Vous vous connectez dans un navigateur réel ; le programme ne reprend la requête qu’une fois cette étape terminée.

La contrainte essentielle est la suivante : ce relais ne doit jamais se déclencher implicitement. Une commande non interactive, qu’il s’agisse de CI ou d’une tâche planifiée, n’ouvre jamais de navigateur. Elle retourne proprement une erreur de session et laisse la couche supérieure décider. Le relais doit également éviter les faux positifs : après une connexion réussie, le runtime ne dispose que d’un bref délai supplémentaire — 20 secondes dans l’implémentation — avant qu’un verdict soit rendu. Si la page métier a déjà redirigé vers une page de compte qui n’offre pas le contexte d’interface visé, terminez immédiatement l’étape en cours. Ne confondez pas un « impossible d’y accéder » déterministe avec un simple chargement en cours, au risque d’attendre bêtement. Un flux qui autorise la dégradation enregistre alors cette étape comme unavailable et continue au lieu de faire échouer l’ensemble.

Statuts d’étape : terminé, ignoré volontairement ou session requise

Tout ce qui précède repose sur le même principe : aucune étape ne doit se contenter de renvoyer « succès » ou « échec ». Dans un pipeline d’orchestration, le résultat d’une étape peut prendre six formes : completed (terminée), empty (exécutée, mais sans données), ready (préparée, en attente de soumission), skipped (ignorée volontairement par règle), unavailable (indisponible pour le moment, ce qui signifie généralement qu’une session est nécessaire), blocked (une précondition manque).

« Ignorée volontairement », « session requise » et « réellement vide » sont trois signaux radicalement différents. Avec un unique résultat opaque, impossible de savoir si ce vide est attendu ou si la session a expiré sans que personne ne s’en aperçoive : le pipeline devient inexploitable. Modélisez le statut d’une étape sous la forme d’un enum fini. La couche d’orchestration, qu’il s’agisse d’un script ou d’un modèle, pourra alors choisir entre dégrader, réauthentifier ou abandonner. C’est le même principe que les trois codes d’erreur du pont passif, transposé au niveau du flux.

Utiliser le modèle pour choisir le bon niveau d’intégration

Le modèle n’intervient qu’ici, dans un rôle volontairement limité : il ne purifie pas la logique à votre place ; il vous aide à déterminer si elle doit l’être, et jusqu’où. C’est une décision d’architecture, pas un casse de signature. La question centrale est simple : l’état dont dépend la logique peut-il être reconstruit statiquement, ou n’existe-t-il qu’au runtime ? À partir de là, vous mettez en balance l’effort de purification et la fréquence des changements. Plusieurs étapes sollicitent le modèle pour des besoins différents :

Étape	Capacité requise	Choix	model id
Lire le module entier pour cartographier la surface de dépendances	Contexte long, lecture du graphe d’appels en une passe	Kimi K3	`kimi-k3`
Argumenter les deux options de niveau et contester le réflexe « faites juste en sorte que ça marche »	Raisonnement solide ; capable de défendre une journée supplémentaire de purification	Claude Opus 5	`claude-opus-5`
Tri initial en masse de dizaines à centaines de capacités	Peu coûteux, forte concurrence	Claude Sonnet 5	`claude-sonnet-5`
Attribution après une dégradation	Raisonnement intermédiaire ; explication à partir d’un journal d’échec	GPT-5.6 Sol	`gpt-5.6-sol`

La deuxième ligne est la plus importante. Lorsqu’il faut choisir un niveau, l’erreur la plus courante consiste à donner au modèle le ton du « faites juste en sorte que ça marche » : il répond alors que « le pont navigateur est le plus simple ». Il vous imite ; il n’évalue pas le coût à long terme à votre place. Un modèle de raisonnement solide rétorquera plutôt : « ce segment est un hash standard avec une perturbation constante ; il mérite une journée de travail pour devenir une fonction pure et ne devrait pas passer par le pont ». Ne me croyez pas sur parole : sélectionnez 3 fragments de logique, dont au moins 1 dont vous connaissez déjà le bon placement pour servir de contrôle. Donnez le même prompt — « propose un niveau, justifie-le et oppose-toi à un passage prématuré sur le pont » — à claude-opus-5 et gpt-5.6-sol. N’observez qu’une chose : le modèle se bat-il pour vous faire remonter d’un niveau, ou choisit-il paresseusement le troisième par défaut ?

Le vrai frein, c’est le coût du changement de modèle

Quatre niveaux provenant de trois fournisseurs : trois SDK, trois schémas d’authentification et trois formats d’erreur. Réécrire votre client pour changer de modèle entre les étapes n’en vaut pas la peine. C’est pourquoi la plupart des équipes finissent par employer un seul modèle partout, y compris pour la décision de placement qui exige justement le plus de raisonnement, avec un modèle qui ne fait qu’approuver.

AIReiter aplanit cette couche : une clé, une interface compatible OpenAI, les quatre niveaux derrière, et le changement se limite au champ model du corps de la requête.

# Argument de placement : niveau de raisonnement
curl https://aireiter.com/api/v1/chat/completions \
  -H "Authorization: Bearer $AIREITER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "messages": [{"role": "user", "content": "<prompt de placement + fragment de logique rétro-ingéniérée + liste des dépendances>"}]
  }'

# Tri initial en masse : modifier un seul champ
#   "model": "claude-sonnet-5"
# Attribution de dégradation :
#   "model": "gpt-5.6-sol"

Vous utilisez déjà le SDK OpenAI ? Faites pointer base_url vers https://aireiter.com/api/v1. Avec le SDK Anthropic, appelez POST /api/v1/messages avec la même clé. Côté prix, les modèles Claude bénéficient de 30 % de réduction sur le tarif catalogue et les modèles GPT sont à moitié prix. Le coût de ce workflow se concentre à deux endroits : le tri initial en masse de dizaines à centaines de capacités, avec Sonnet et un fort volume d’appels, puis l’entrée longue consistant à lire un module entier pour en établir la surface de dépendances, avec Kimi et beaucoup de tokens par appel. Le tri en masse s’exécute sur un modèle Claude : la remise s’applique donc directement à l’étape la plus dense. L’argumentation de placement au niveau raisonnement repose également sur un modèle Claude, avec 30 % de réduction. Le niveau long contexte de Kimi K3 est disponible avec la même clé.

Obtenir une clé API
Essayer sans inscription — commencez par fournir manuellement quelques fragments de logique et observez si les deux modèles vous approuvent ou contestent le choix du pont navigateur.

En conclusion

Intégrer une logique rétro-ingéniérée n’est pas un problème purement technique : c’est un problème de coût. L’échelle à trois niveaux — réécriture native > moteur JS local > pont navigateur passif — ne doit pas être inversée, car chaque niveau inférieur remplace une fonction pure par un processus soumis à des dépendances externes, à une intervention humaine et à un onglet actif. Le pont passif n’est pas interdit ; c’est un composant provisoire aux limites strictes : un instantané unique, jamais d’action, une erreur explicite dès qu’une page manque, aucun état sensible hors du navigateur, une connexion uniquement via relais explicite, et des statuts d’étape toujours lisibles. Respectez ces règles, et vous obtenez une solution de transition fiable ; abandonnez-en une seule, et vous créez une boîte noire que personne n’osera maintenir. Le modèle vous aide à décider où placer une capacité et à résister à l’inertie du « faites juste en sorte que ça marche ». Quant à savoir si chaque réécriture est correcte, le juge reste le test différentiel, pas le modèle.