Un enchaînement que personne n'a modernisé

Les outils d'interception du trafic ont à peine changé en dix ans, et l'enchaînement qu'ils imposent en est la raison. Lancer le mandataire, capturer ce qui passe, regarder la requête de ses propres yeux, décider de ce qui ne va pas, puis la modifier à la main — encore, et encore, pour chaque variante que l'on veut essayer. Ces outils réussissent la capture et laissent entièrement le raisonnement à la personne. Et ce n'est pas une petite quantité de raisonnement : lire un en-tête, comparer un corps de réponse avec ce que la documentation promettait, reconstituer la séquence qui a produit l'échec — c'est là que le temps passe réellement.

RelayCraft part d'une observation : une IA est désormais assez bonne exactement sur cette partie et totalement incapable d'y accéder, parce que le trafic vit dans une application qu'elle ne voit pas. La solution consiste à exposer le trafic par une interface standard afin que l'assistant travaille sur les mêmes données que l'humain a sous les yeux.

Ce que l'assistant peut réellement faire

L'outil fait tourner un mandataire local et un serveur MCP — un protocole ouvert qui remet outils et données à un client d'IA. Une fois un assistant connecté, il peut lire les requêtes et réponses capturées, déterminer laquelle échoue et pourquoi, réécrire des paramètres ou remplacer un corps de réponse, et exécuter une série de cas à la suite plutôt qu'un par un. La décision reste humaine ; la différence est que décider et agir se font sur le même objet.

Cela change la forme du travail d'intégration plutôt que de simplement l'accélérer. Au lieu de capturer une requête, de la lire, d'ouvrir un éditeur et de changer une valeur, on décrit le résultat attendu et on inspecte le résultat obtenu — et quand il est faux, la version précédente est à un pas au lieu d'avoir disparu. La même propriété rend les tests d'interfaces et l'analyse de trafic moins fastidieux : décrire un cas en mots et le faire exécuter contre le flux capturé est une activité différente que d'écrire un script pour cela.

Un cœur compilé plutôt qu'une page web emballée

Le choix technique pèse plus lourd que la commercialisation ne l'admet d'ordinaire. Beaucoup d'outils de bureau de cette catégorie sont une interface web dans un moteur de navigateur embarqué, ce qui explique leur démarrage lent et une occupation mémoire sans rapport avec le travail effectué. Celui-ci utilise la vue web que le système fournit déjà et place le moteur mandataire dans un cœur compilé écrit en Rust : le travail lourd — interception, déchiffrement, réécriture — s'exécute en code natif tandis que l'interface reste actuelle.

Le socle fonctionnel est là où il doit être pour qui fait cela professionnellement : déchiffrement HTTPS, points d'arrêt sur les requêtes, rejeu et remplacement par règles. Ce ne sont pas des différenciateurs, c'est le minimum, et un outil qui s'y trompe est inutilisable, si bon soit son assistant. L'affirmation qui mérite d'être testée est que la combinaison — un moteur natif et une IA qui l'atteint — vaut plus que la somme des parties.

Local, ce qui ici n'est pas un slogan

Le trafic capturé depuis une application d'entreprise contient régulièrement des jetons de session, des noms d'hôtes internes et des charges qui ne devraient pas quitter le bâtiment. La conception garde les données en local : capture, déchiffrement et réécriture se font sur la machine, rien n'est téléversé. La connexion à l'IA passe par le protocole local vers un client que l'on utilise déjà, ce qui signifie que les requêtes ne voyagent jamais vers les serveurs de l'outil — il n'en existe aucun où aller.

Cette distinction mérite d'être formulée précisément, car c'est la différence entre une promesse de confidentialité et une posture. Vos requêtes atteignent bien le modèle qu'utilise l'assistant, exactement comme si vous les colliez dans une fenêtre de discussion ; ce qui n'arrive pas, c'est une copie supplémentaire envoyée à l'éditeur de l'outil. Pour des interfaces internes et tout ce qui porte des identifiants, c'est l'arrangement dont les gens ont réellement besoin, et il vaut la peine d'être compris plutôt que cru.

Par une personne, avec une IA, en quelques mois

L'origine est la partie qui date le projet. Un développeur unique l'a construit de zéro en quelques mois, avec l'aide d'une IA tout du long — la manière de travailler devenue assez courante pour porter un nom. C'est un indice vraiment intéressant sur la vitesse à laquelle une personne compétente peut désormais produire un outil de ce genre, et c'est aussi l'explication honnête du rythme du projet comme des aspérités que l'on rencontrera.

Il est entièrement libre, ce qui veut dire que le code peut être lu, modifié, étendu et reconstruit ; la communauté a déjà apporté des extensions, formulé des demandes et l'a intégré dans ses propres flux de travail. Pour un outil qui manipule des identifiants, pouvoir lire le code n'est pas une préférence philosophique mais le seul moyen de savoir ce qu'il en advient.

À qui cela s'adresse

Aux développeurs qui raccordent un front à un back, où le travail est une boucle de capture, comparaison, ajustement et nouvel essai, et où un assistant capable d'effectuer l'ajustement retire l'essentiel des frictions. À ceux qui testent des interfaces et préfèrent décrire un cas plutôt que le scripter. Aux chercheurs en sécurité qui parcourent du trafic déchiffré, pour qui pointer un assistant vers une séquence suspecte est plus rapide que de la lire ligne à ligne. Et à tous ceux qui font cela depuis dix ans avec un vieil outil parce que rien de meilleur n'était arrivé.

La proposition est étroite et claire : donner un cerveau à l'outil de capture. Il ne s'agit plus de fixer le trafic en devinant, mais de décrire le problème et de regarder la modification se faire. Pour des développeurs dont la journée consiste en ce travail, une demi-heure d'essai est un investissement raisonnable, et le traitement local comme l'ouverture du code rendent la question de la confidentialité répondable au lieu d'être seulement rassurante.

Le résumé honnête

Ce qui est nouveau ici, c'est la connexion et non les composants : les mandataires existent, le protocole existe, les assistants existent, et l'apport consiste à les mettre dans la même boucle. L'ingénierie dessous est solide — un cœur compilé, un moteur natif, le socle fonctionnel couvert —, et les limites sont celles d'un jeune projet construit rapidement par une personne : des aspérités, un ensemble de fonctions encore en cours de remplissage et une forme à long terme qui n'est pas encore fixée. Rien de cela ne change l'argument. Si votre travail est le trafic, un assistant qui peut le lire et le réécrire est un autre genre d'outil que celui qui se contente de vous le montrer.