AIDiveIntro : visez-vous d'abord
Pointez REA sur votre propre app avant que quelqu'un d'autre ne la démonte. Nous l'avons lancé sur notre site en ligne depuis un bac à sable cloud jetable, corrigé ce qu'il a trouvé, et livré la pull request.
REA est la skill de rétro-ingénierie que toute une vague de vidéos a braquée sur les logiciels des autres. Sur notre site, il lui a fallu moins de treize minutes et pas une seule requête d'écriture pour montrer que n'importe quel site web pouvait remplir notre liste mail. Il a aussi trouvé le plafond quotidien de notre bot de commentaires, écrit en clair dans le JavaScript que notre site vous fait télécharger. Après le correctif, la requête qui passait autrefois est refusée.
Le résultat, ce sont six règles pour lancer le même audit sur votre app : le bac à sable jetable, la cible exacte, le tri des résultats, la config dans votre bundle, les freins sur les endpoints, et la preuve du correctif.
Ce qu'est REA et comment l'installer
REA signifie Reverse Engineer Anything : un ensemble d'outils qui permet à Claude Code de démonter l'app que vous livrez. La rétro-ingénierie consiste à comprendre comment quelque chose est construit à partir du produit fini, comme un mécanicien qui lit une voiture sans les plans d'usine.
Au lieu de lire votre code source, REA lit le bundle, c'est-à-dire le JavaScript que votre site envoie réellement à chaque visiteur. À partir de ce bundle, il liste les routes, les endpoints que vos pages appellent, et tout ce que vous y avez laissé par erreur. Il ne peut pas vous rendre le code source, car vous n'obtenez que des preuves, et sa propre documentation précise que ce n'est pas un bac à sable non plus.
Pour l'installer :
- Installez REA depuis son paquet officiel et épinglez la version, car il a sorti six versions en une semaine.
- Lancez son setup pour Claude Code.
- Activez le profil compact, puisqu'il charge bien plus d'une centaine d'outils dans votre session.
- N'installez que depuis le dépôt officiel, car de fausses copies contenant des malwares circulent déjà.
Quand nous avons lancé l'installation dans notre bac à sable, l'agent a d'abord vérifié que le paquet pointait bien vers le dépôt officiel avant de toucher à quoi que ce soit. Le setup a ensuite installé la skill mais aucun serveur d'outils, si bien que Claude Code a simplement utilisé les versions en ligne de commande des mêmes outils. Si vos outils n'apparaissent pas après le setup, inutile de redémarrer : appelez les mêmes étapes depuis le terminal.
Règle 1 : lancez-le là où il ne peut pas nuire
La première règle concerne l'endroit où vous le lancez. Vous allez laisser un agent piloter un navigateur et exécuter des outils téléchargés contre votre app en production. Sur votre portable, cet agent se trouve à côté de vos clés, de vos autres projets et de tous les comptes où vous êtes connecté. Les notes de sécurité de REA le disent sans détour : ce n'est pas un bac à sable.
Un bac à sable est une machine jetable : ce qui tourne mal reste dedans, et vous la supprimez. Ouvrez un bac à sable jetable sur votre dépôt et faites tout l'audit là-dedans, jamais sur votre propre machine.
Nous avons utilisé Kosuke, qui fait tourner Claude Code sur votre propre abonnement dans une machine cloud jetable. Vous choisissez votre dépôt, vous dites à l'agent de déploiement comment votre app démarre, et il vous donne une preview, un lien où votre app en cours d'exécution apparaît. Chaque chat reçoit aussi sa propre branche, c'est-à-dire sa propre copie du code, et se termine par une pull request. Quand nous avons importé notre site, l'agent a installé le gestionnaire de paquets et un navigateur headless, mesuré la mémoire et choisi tout seul la taille de la machine. Quelques minutes plus tard, notre vrai site tournait à côté du chat, sur une branche que personne d'autre ne touche.
Un piège rencontré lors d'un test précédent : une app Next.js toute neuve s'affichait dans la preview, mais rien ne répondait sur la page. Le correctif tient en une ligne dans votre config Next qui autorise l'adresse de la preview, et la page reprend vie.
La limite, c'est qu'il s'agit du même Claude Code avec une boîte autour, donc une machine virtuelle locale ou un conteneur fait le même travail. Ce qui compte, c'est la boîte, pas la marque.
Transparence : Kosuke nous a donné un accès gratuit à sa meilleure formule. Entrez le code AIDIVE2026 dans le champ « Promo code » juste après l'inscription et vous obtenez trente dollars de crédits au lieu des dix habituels.
Règle 2 : une URL exacte, toute écriture bloquée
La deuxième règle, c'est ce que vous dites réellement à REA. Si vous lui dites simplement « audite mon app », la skill de REA s'arrête et demande de quelle app il s'agit.
REA n'ouvre jamais de navigateur de lui-même, donc vous en lancez un avec un port de débogage, une porte qui permet à un outil d'observer tout ce que fait la page. Mettez-le en place dans cet ordre :
- Gardez le port de débogage sur le loopback, l'adresse que seule votre machine peut joindre, et donnez au navigateur un profil vierge.
- Bloquez toute requête d'écriture avant le chargement de la moindre page, pour que l'audit puisse lire votre site mais ne puisse ni envoyer un formulaire ni rien modifier.
- Seulement ensuite, donnez à REA les pages exactes que vous voulez lui faire lire.
Dans notre prompt, nous avons nommé deux pages de notre club gratuit et écrit une règle en mots simples : n'envoie jamais d'écriture au site en ligne. C'était important, car le formulaire de ces pages alimente une vraie liste mail avec de vraies personnes dessus. L'agent a pris la règle au sérieux et a écrit son propre petit garde-fou qui laissait passer les lectures et arrêtait tout le reste. Pendant l'audit, ce garde-fou a stoppé six tentatives venant du script d'analytics, et pas une seule requête n'a jamais atteint notre formulaire d'inscription.
REA a ensuite fait son travail : inspecter chaque page, lire chaque bundle, prendre des captures d'écran et exporter les scripts en dehors du dépôt.
La limite, c'est que REA ne voit que ce qui se charge pendant qu'il est attaché, donc tout ce qui s'est passé avant reste une inconnue dans le rapport. Malgré cela, vous avez maintenant un rapport sur votre propre app en ligne, écrit sans toucher à la moindre de ses données.
Règle 3 : triez chaque résultat avant d'en corriger un
La troisième règle est de trier avant de corriger. Un rapport comme celui-ci est plein de lignes alarmantes et vous aurez envie de tout corriger d'un coup.
La skill de REA veut que chaque conclusion soit marquée comme une observation, une inférence ou une inconnue, avec un identifiant de preuve. C'est ce qu'il a vu, ce qu'il a supposé, et ce qu'il n'a pas pu voir, et l'identifiant de preuve est un reçu que vous pouvez vérifier. Triez d'abord chaque résultat ainsi, en vous appuyant uniquement sur la vue de l'extérieur, et commitez cette version avant d'ouvrir un seul fichier source. Lisez ensuite votre source et marquez chaque ligne comme vraie fuite, voulue par conception, ou faux positif.
Notre rapport comptait quinze résultats :
| Résultat | Ce que REA a vu | Notre verdict |
|---|---|---|
| Endpoint d'inscription | Aucune limite et aucune vérification du site appelant, donc n'importe quel site pouvait faire abonner n'importe quelle adresse à notre liste via le navigateur d'un visiteur | Vraie fuite, la pire |
| Barrière email sur les packs gratuits | Le pack entier est déjà dans la page chargée ; une ligne dans la console du navigateur retire la barrière, ou le mode lecture affiche le texte | Voulu par conception |
| Source maps, clés, cookies | Aucun dans les bundles, aucun cookie nulle part | Bonne nouvelle |
La barrière est voulue par conception parce que les packs sont gratuits exprès, et notre propre code dit qu'un formulaire cassé ne doit jamais cacher une page gratuite.
La limite, c'est la colonne des inconnues. REA ne peut pas voir ce que fait votre serveur, donc vous réglez ces lignes en lisant votre code serveur.
Règle 4 : votre bundle livre votre config
La quatrième règle porte sur ce que votre bundle transporte, car un seul fichier de réglages partagé peut voyager jusqu'à chaque visiteur sans que vous le remarquiez.
Voici comment ça arrive. Vous importez votre config dans un helper, et deux petits composants interactifs utilisent ce helper. Le bundler, l'outil qui assemble votre code en fichiers que le navigateur télécharge, ne sait pas quelles clés ils utilisent, donc il les livre toutes.
C'est exactement ce que REA a trouvé dans notre JavaScript. Toute la config de notre site se trouvait dans un seul fichier, avec l'ID de notre liste mail, nos dossiers de build, et les limites du bot qui répond aux commentaires de nos vidéos. Il disait même combien de réponses ce bot envoie par jour, cent, et combien d'erreurs déclenchent son interrupteur de sécurité. Les deux composants qui l'importaient ne lisaient que le nom du site et la liste des langues.
La règle : cherchez dans votre JavaScript livré vos propres clés de config, et ne donnez aux composants client que les champs qu'ils lisent. Dans notre bac à sable, l'agent a découpé la config en une minuscule version navigateur avec seulement ces champs, et le reste est resté côté serveur. Il a aussi ajouté une étape de build qui échoue si une clé serveur réapparaît un jour dans un fichier livré, pour que vous ne puissiez pas revenir en arrière.
Rien de tout cela n'était un mot de passe, mais tout ce qui se trouve dans ce fichier est public, donc vos secrets ne vivent que dans des variables serveur.
Règle 5 : chaque endpoint ouvert reçoit un frein
La cinquième règle a corrigé notre vraie fuite, et elle s'applique dès que vous avez un formulaire public qui appelle un service payant : votre liste email, votre modèle d'IA ou votre passerelle de SMS. Vous l'appelez via une petite fonction serveur écrite en un après-midi. La nôtre prenait un email et le passait directement à la liste mail, et n'importe quel autre site pouvait faire envoyer cette requête par le navigateur d'un visiteur.
La check-list de sécurité de référence le dit clairement : votre contrôle d'accès ne fonctionne que dans du code que l'attaquant ne peut pas modifier, c'est-à-dire votre serveur. Mettez donc des freins sur chaque endpoint de ce type :
- Vérification de l'Origin. Le header Origin est le tampon qu'un navigateur appose sur une requête pour indiquer quel site l'a envoyée, donc un formulaire hébergé sur un autre site est refusé.
- Rate limit. Un plafond sur le nombre de requêtes qu'un visiteur peut envoyer dans une courte fenêtre.
- Consentement vérifié côté serveur. La case que vous cochez voyage réellement avec la requête.
Dans notre bac à sable, l'agent les a tous écrits dans notre Worker, la petite fonction qui s'exécute devant vos pages quand on les visite. Il les a ensuite testés contre un faux service de mailing, jamais le vrai, et chaque requête a été refusée exactement là où elle devait l'être. Si vous envoyez depuis le mauvais site, vous êtes refusé. Votre sixième requête en une minute est refusée aussi, et sans consentement vous êtes rejeté.
La limite, c'est qu'un script peut falsifier le tampon Origin, et que le rate limit compte par emplacement, donc le vrai correctif est la double confirmation par email.
Règle 6 : relancez, vérifiez à la main, livrez la PR
La sixième et dernière règle est de prouver le correctif, car un mur de coches vertes est précisément le moment où l'on arrête de regarder. Un développeur qui a testé REA sur une app de bureau a écrit sur HackerNoon qu'il avait raté des points d'entrée que l'app avait bel et bien.
Relancez donc les mêmes étapes REA sur le build corrigé, vérifiez chaque correctif à la main depuis le terminal, et seulement ensuite ouvrez la pull request.
Sur le build corrigé, la requête qui passait par notre formulaire d'inscription est refusée. Nos clés serveur avaient disparu de tous les fichiers livrés, les headers de sécurité étaient là, et les tests du Worker sont passés de l'échec à la réussite. La barrière sur nos packs gratuits était toujours ouverte, ce que nous avons décidé, et le rapport le dit à côté de chaque ligne.
L'agent a ensuite ouvert la pull request. Les rapports n'y figurent que parce que nous les avions demandés dans le prompt. La check-list de test que Kosuke construit est restée dans la session, sans rien publier sur la pull request elle-même. Si votre relecteur ne lit que GitHub, mettez vous-même les rapports avant et après dans la pull request.
Nous avons ensuite repris le même changement dans notre propre code, et il sera en ligne au prochain déploiement de notre site.
Verdict : quand viser REA sur soi-même
Toute l'opération, c'était REA braqué sur notre propre site en ligne depuis un bac à sable jetable, chaque résultat trié, les vraies fuites corrigées, un nouvel audit, puis une pull request. Le résultat qui justifiait tout le reste était le premier : n'importe quel site pouvait remplir notre formulaire d'inscription avec l'adresse de n'importe qui.
Lancez cet audit avant de livrer quoi que ce soit avec un formulaire public ou un service payant derrière, et de nouveau chaque fois que vous changez ce qui est livré. Ne le lancez pas sur un logiciel qui ne vous appartient pas, car le disclaimer de REA le limite aux logiciels que vous possédez ou que vous êtes autorisé à examiner. Et il ne remplace jamais la lecture de votre code serveur, car c'est exactement là que vivent les inconnues.
Si vous ne retenez qu'une règle, retenez celle-ci : lancez-le sur vous-même, dans une boîte, et ne corrigez que ce que vous avez trié.
Le prompt exact, le tableau de tri et le correctif du Worker que nous avons livré se trouvent dans le kit gratuit de cette vidéo.
