En août, nous avons publié une vérification en deux questions pour les prompts de configuration écrits à l'intention de votre assistant IA : écrit-il dans la configuration globale de l'assistant, et cherche-t-il à convaincre l'assistant de ne pas confirmer avec vous d'abord ? L'exemple à éviter, alors, était un paquet qui échouait aux deux. Deux mois plus tard, nous avons évalué un deuxième outil de la même catégorie, un module complémentaire de rétro-ingénierie pour agents de code appelé REA, et il passe les deux questions aussi proprement que tout ce que nous avons lu : l'installation montre son plan avant d'écrire, attend l'approbation, et livre des instructions qui disent à l'agent de demander plutôt que d'agir.[1] Nous ne l'avons quand même pas adopté. Les raisons n'avaient rien à voir avec la sécurité, et elles valent pour tout module complémentaire que quelqu'un propose pour les outils d'IA de votre équipe.
Les six portes, dans l'ordre où nous les appliquons : (1) l'hygiène d'installation, l'outil encadre-t-il ses propres écritures ; (2) l'adéquation au créneau, vendez-vous ou utilisez-vous le travail qu'il fait ; (3) la compatibilité des postes, fonctionne-t-il sur les machines que vos gens utilisent ; (4) la cadence des versions, pouvez-vous épingler une version et rester dessus ; (5) l'empreinte, se charge-t-il dans chaque session ou dans un seul projet ; (6) le cas d'usage et les données, l'usage vedette est-il légal pour vous et où va le résultat. La version liste de contrôle, écrite pour un propriétaire ou un responsable des opérations, se trouve à la fin.
Première porte : le test de sécurité, réussi.
Les deux questions d'août portaient sur l'hygiène d'installation : ce qu'un outil fait à la configuration de votre assistant quand l'assistant l'installe à votre place.[3] L'installation de REA suit le bon modèle. Son programme d'installation propose les agents qu'il a détectés dans une liste à sélection multiple et laisse non sélectionnés ceux qui viennent d'être détectés ; selon la documentation, « detection gives setup context, not permission to add a new registration » (en anglais dans l'original ; la détection fournit un contexte d'installation, pas la permission d'ajouter un nouvel enregistrement).[1] Avant d'écrire quoi que ce soit, il liste chaque chemin de configuration qu'il touchera, chaque endroit où il copiera sa compétence, chaque paquet externe, chaque origine réseau et la preuve d'intégrité qui s'y rattache, et il n'écrit rien tant que ce plan n'est pas approuvé. L'installation du seul moteur d'analyse natif qu'il peut récupérer pour vous demande une approbation distincte.
La compétence qu'il remet à l'agent est écrite dans le même esprit. Quand l'outil n'est pas enregistré, la compétence dit à l'agent de diagnostiquer sans modifier de fichiers, de montrer le plan à blanc (dry run) avec ses chemins exacts et ses sauvegardes, et, selon sa formule, « obtain approval before setup writes configuration or installs Hopper » (obtenir l'approbation avant que l'installation n'écrive la configuration ou n'installe Hopper).[1] (Hopper est le seul moteur d'analyse que le programme d'installation peut récupérer pour vous.) Elle dit aussi à l'agent de ne pas installer de logiciel sans rapport pour réparer un enregistrement. C'est l'inverse du cas d'août, dont le fichier de routage disait à l'agent de s'écrire lui-même dans la configuration globale et qu'une réponse « compris » était un échec.[2]
Deux autres éléments jouent en sa faveur. Sa politique de sécurité énonce une frontière et la limite de cette frontière d'un même souffle : des jetons par session sur des sockets de l'utilisateur courant, des projets temporaires isolés pour le moteur d'analyse, puis « This is not a sandbox » (ce n'est pas un bac à sable), avec l'énoncé clair que l'ouverture d'un binaire non fiable exécute le moteur d'analyse avec les permissions de votre utilisateur.[1] Et une recherche ciblée dans le code source, pour des bibliothèques d'analytique courantes et des appels sortants, n'a rien trouvé au-delà du téléchargement du moteur et des récupérations de source maps pendant l'analyse de sites web. C'était un grep, pas un audit.
Première porte, donc : réussie. En août, cette porte était toute la note. Ici, c'est là que l'évaluation commence.
Ce que nous avons évalué, et ce que nous n'avons pas fait.
REA est un serveur MCP local (une cinquantaine d'outils dans son catalogue généré, selon notre décompte sur le commit relevé) plus une compétence d'agent livrée avec l'outil, de 14 ko, accompagnée de cinq fichiers de référence, et les mêmes flux de travail sous forme d'outil en ligne de commande. MCP, le Model Context Protocol, est la norme de branchement qui permet à un agent de code d'appeler des outils extérieurs. Une compétence est un fichier texte d'instructions que l'agent charge et suit. Un « module complémentaire » dans cette note désigne un serveur MCP, une compétence, ou les deux. L'argumentaire de REA, mot pour mot tiré de son README : « See a feature in an app that you want in your own product? Ask your agent to investigate it with REA. » (vous voyez dans une application une fonction que vous voulez dans votre propre produit ? Demandez à votre agent de l'examiner avec REA).[1] Ses cibles vont des binaires natifs aux micrologiciels, aux captures réseau enregistrées et aux sites web en ligne, en passant par les applications JavaScript et Electron, les assemblages .NET et les paquets Android. Il est écrit en TypeScript, testé contre les vrais moteurs d'analyse dans son intégration continue, et il est populaire. Nous laissons de côté le nombre d'étoiles : il bouge, et la popularité n'est pas une porte.
Nous ne l'avons pas exécuté. Nous ne l'avons pointé sur aucun binaire, paquet ou site web, les nôtres ou ceux de quiconque. Les affirmations sur ses capacités sont celles du projet. Nous ne nous sommes pas non plus fait d'opinion sur la rétro-ingénierie comme pratique. La partie la plus pointue de ce travail (binaires, micrologiciels, vidages après plantage) est du travail que notre volet de services gérés de TI dirige vers un partenaire spécialisé, et c'est la deuxième porte.
Cinq autres portes.
La vérification d'août ne vous dit pas si l'outil a même sa place dans votre trousse d'outils. Un outil peut être honnête sur ce qu'il écrit et rester le mauvais outil pour votre entreprise, mal fonctionner sur vos machines, évoluer plus vite que vous ne pouvez lire, se charger dans des sessions qui n'en avaient jamais besoin, et viser un cas d'usage que votre avocat n'a pas vu. Ce sont cinq questions distinctes, et nous avons constaté que nous les posions dans un ordre fixe.
Adéquation au créneau : vendez-vous ou utilisez-vous ce travail ?
Le centre de gravité de REA, c'est l'analyse native approfondie, celle des micrologiciels et des binaires. Nous ne faisons pas ce travail ; quand un client en a besoin, nous le dirigeons vers un partenaire. Son autre moitié, l'analyse de sites web (structure des pages, scripts, observations réseau, captures d'écran), fait double emploi avec des outils que nous utilisons déjà pour le travail que nous vendons. La partie que nous utiliserions est donc redondante, et la partie unique est hors de notre créneau d'affaires. Pour une autre firme, une firme de sécurité Linux qui mène des mandats autorisés, cette porte se lit à l'inverse. La question vous revient, pas à l'outil.
Compatibilité des postes : tourne-t-il là où travaillent vos gens ?
Nous travaillons sous Windows. Des trois moteurs d'analyse natifs de REA, l'un ne tourne pas du tout sous Windows, un autre y est documenté comme un mode expérimental en lecture seule, et le troisième exige sa propre licence commerciale. La capture de processus et l'extraction de micrologiciels ne fonctionnent que sous Linux ou macOS. Ce qui fonctionnerait sur nos postes de travail, c'est la moitié statique : les arborescences JavaScript et Electron, les assemblages .NET, les paquets Android (avec un kit Java installé) et les captures réseau enregistrées.[1] Un outil qui tourne sur vos portables à une fraction de sa capacité annoncée n'est pas le même outil que celui du README, et c'est cette fraction qu'il faut évaluer.
Cadence des versions : pouvez-vous rester sur une version ?
Entre le 7 et le 9 octobre 2026, le projet a publié cinq versions, dont deux sauts de version majeure. Son README le dit sans détour : « REA changes quickly, and new releases include frequent bug fixes. Keep your installation up to date. » (REA évolue rapidement, et les nouvelles versions contiennent de fréquents correctifs. Gardez votre installation à jour).[1] Pour une installation personnelle, c'est un atout. Pour un outil que votre agent appelle dans du travail de client, c'est une question : pouvez-vous épingler une version (figer la version installée pour que les mises à jour n'arrivent que lorsque quelqu'un la déplace) et la garder un mois ? Ici, la réponse honnête est « oui, si vous le faites vous-même ». Les commandes de réparation de la compétence récupèrent ce qui est publié à cette heure-là (le nom du paquet suivi de latest), de sorte qu'un correctif de routine vous ferait passer à une version que personne dans votre équipe n'avait lue. C'est une question de chaîne d'approvisionnement en termes simples : le paquet que votre agent installera la semaine prochaine n'est pas celui que vous avez lu. L'installation montre quand même son plan et attend ; c'est donc un risque de dérive de version, pas d'injection, et c'est pourquoi il y a six portes et non une seule.
Empreinte globale : qu'est-ce qui se charge dans chaque session ?
L'installation standard enregistre le serveur à la portée utilisateur, c'est-à-dire pour tout votre compte plutôt que pour un seul projet, et copie la compétence dans le dossier personnel de compétences de l'agent. Cela signifie qu'environ cinquante définitions d'outils et un fichier d'instructions de 14 ko se chargent dans chaque session que votre agent ouvre, y compris chaque session sans besoin de rétro-ingénierie, ce qui, pour nous, représenterait presque toutes.[1] Chaque définition d'outil que porte votre agent est du texte qu'il lit avant de lire votre tâche, et ce coût s'additionne dans toute la trousse d'outils. REA permet toutefois une forme plus étroite : sauter son programme d'installation et enregistrer le serveur à la main, épinglé à une version, dans la configuration d'un seul projet. Des cinq portes au-delà de l'hygiène d'installation, c'est celle qu'il a franchie proprement pour nous, et seulement parce que le projet laisse cette porte ouverte.
Légalité du cas d'usage et sortie des données : que fait l'usage vedette, et où va le résultat ?
Le cas d'usage vedette, rebâtir une fonction vue dans l'application de quelqu'un d'autre, se heurte aux conditions de licence de cette application, qui interdisent couramment la décompilation. L'avis de non-responsabilité du projet met le fardeau là où il doit être, sur l'utilisateur : « You are responsible for obtaining any required authorization and complying with applicable laws. » (il vous incombe d'obtenir toute autorisation requise et de respecter les lois applicables).[1] Nous n'avons pas d'avocat attitré, de sorte que ce cas d'usage reste fermé pour nous tant qu'un avocat n'a pas lu les conditions d'une cible précise, et rien dans cette note ne doit être lu comme une approbation de cet usage.
La question des données est distincte et plus discrète. L'analyse s'exécute localement, et le README le dit, mais il dit aussi que les résultats vont à votre agent, dont le « model provider has its own data policy » (le fournisseur du modèle a sa propre politique de données).[1] Le résultat décompilé de l'application héritée d'un client est une information confidentielle du client, et selon notre règle de traitement des données, il n'atteint pas un modèle hébergé sans le consentement écrit de ce client. Pour une entreprise québécoise, c'est une question transfrontalière au regard de la Loi 25.
Les six portes, deux outils.
Lues côte à côte avec le cas d'août, les deux évaluations donnent un tableau que vous pouvez réutiliser. La première rangée est la seule qu'un test de sécurité couvre.
Cinq versions en trois jours.
Nous avons mis la rangée de la cadence dans une figure parce que c'est la porte qu'on prend pour un compliment. Un projet qui avance vite a l'air vivant. La question opérationnelle est autre : votre agent appelle ce serveur dans du travail que vous facturez, et cinq versions en trois jours signifient que l'outil testé mardi n'est pas l'outil en marche vendredi, à moins que quelqu'un ne l'ait épinglé.
- v5.0.07 oct. · 17:26majeure
- v6.0.08 oct. · 09:40majeure
- v6.1.09 oct. · 01:08
- v6.2.09 oct. · 16:51
- v6.3.09 oct. · 23:56
À quoi ressemble un non motivé.
Ne pas adopter est un verdict, pas une interdiction, et la différence compte quand un vrai besoin se présente. Notre décision en vigueur comporte trois volets.
Rien de global. Aucun enregistrement à la portée utilisateur, aucune compétence dans le dossier personnel.
Limité au projet et épinglé si un mandat l'exige. Un enregistrement épinglé à une version dans la configuration de ce seul projet, jamais par le programme d'installation, de sorte qu'il se charge pour ce travail et nulle part ailleurs, et nous relisons les notes de version avant de déplacer l'épingle.
Un seul déclencheur sur lequel nous agirions. L'application héritée d'un client dont le code source est perdu, où récupérer la logique d'affaires est la demande du client et relève des données du client, avec consentement écrit pour que le résultat de l'analyse atteigne un modèle hébergé. Le cas d'usage vedette, l'application de quelqu'un d'autre, ne figure pas sur la liste.
La liste de contrôle en six portes pour votre prochain module complémentaire d'IA.
Quelqu'un de votre équipe vous proposera ce trimestre un serveur MCP ou une compétence d'agent, probablement un bon. Voici les six questions, dans l'ordre où nous les posons, écrites pour le propriétaire ou le responsable des opérations d'une PME plutôt que pour un développeur. Les deux premières prennent une minute ; les quatre autres demandent une conversation.
- Encadre-t-il ses propres écritures ?
Les questions d'août. Montre-t-il son plan et attend-il l'approbation ? Reste-t-il à l'écart de la configuration globale que vous n'avez pas choisie ? Y a-t-il un langage conçu pour empêcher l'agent de vous demander ? S'il échoue ici, arrêtez ; rien de ce qui suit n'a d'importance.
→ drapeau rouge : écrit avant l'approbation, ou convainc l'agent de ne pas demander - Vendez-vous ou utilisez-vous ce travail ?
Nommez la ligne de service ou la tâche interne qu'il sert. Si la partie unique est du travail que vous dirigez vers d'autres et que la partie familière fait double emploi avec un outil que vous avez déjà, c'est une installation personnelle, pas un outil d'équipe.
→ cible : un flux de travail nommé qu'il améliore - Tourne-t-il là où travaillent vos gens ?
Lisez le tableau des plateformes en regard des portables que vous possédez vraiment, fonction par fonction, et notez lesquelles survivent. Évaluez cette liste, pas celle du README.
→ cible : la liste des fonctions qui survivent - Pouvez-vous rester sur une version ?
Regardez la cadence des versions et vérifiez si les chemins de mise à jour ou de réparation de l'outil récupèrent latest. Décidez qui lit le journal des modifications et quand l'épingle a le droit de bouger. Notez qui publie les versions ; un projet d'une seule personne, c'est une épingle qui repose sur une seule personne.
→ cible : une version épinglée et un responsable désigné de l'épingle - Qu'est-ce qui se charge dans chaque session ?
Préférez un enregistrement limité au projet à un enregistrement global. Si l'outil n'offre que le global, comptez les définitions d'outils qu'il ajoute aux sessions qui ne s'en serviront jamais, parce que l'agent les lit toutes avant de lire votre tâche.
→ cible : portée projet, épinglé - Que fait l'usage vedette, et où va le résultat ?
Lisez d'abord la licence de l'outil lui-même (REA est sous licence MIT ; un outil à code source disponible, c'est une autre conversation, voir la note sur n8n), puis l'avis de non-responsabilité du projet et, pour toute cible qui n'est pas la vôtre, ses conditions de licence, avant la première exécution. Ensuite, suivez le résultat à la trace : une analyse locale se termine quand même dans un modèle hébergé, sauf si vous faites tourner le modèle vous-même. Le contenu du client exige d'abord le consentement du client.
→ cible : conditions lues, consentement au dossier, chemin du résultat tracé
Notez les réponses avec la date et la version. Dans six mois, quelqu'un demandera pourquoi vous avez dit non, et un tableau daté répond plus vite qu'un souvenir.
Ce que cette note ne prétend pas.
Ce n'est pas une évaluation de la qualité de REA. Nous ne l'avons pas exécuté. Les affirmations sur ses capacités sont celles du projet, et le travail d'ingénierie que nous avons lu (installation conditionnée par une approbation, frontière de sécurité énoncée avec ses limites, tests contre les vrais moteurs) se lit comme du travail soigné.
Ce n'est pas une affirmation que REA est non sécuritaire. Il a franchi la seule porte qui concerne la sécurité. Le non est venu des cinq qui portent sur nous.
C'est un instantané daté. Lu le 10 octobre 2026 à la version 6.3.0. Selon la porte de la cadence, l'outil aura changé d'ici à ce que vous lisiez ceci ; revérifiez avant de vous fier à une rangée.
Le non est le nôtre. Une firme de sécurité Linux avec un avocat attitré et des mandats autorisés remplit la colonne de droite autrement. Les rangées sont réutilisables ; le verdict ne l'est pas.
Ceci n'est pas un avis juridique. Les conditions de licence et les obligations de la Loi 25 dépendent de la cible et des données. Nous nommons les questions et qui devrait y répondre.
Si quelqu'un a proposé un serveur MCP ou une compétence d'agent pour votre équipe et que vous voulez qu'on lui applique les six portes, envoyez-nous le dépôt par le formulaire de contact. Nous vous répondrons gratuitement, avec le tableau daté. Les décisions d'admission d'outils comme celle-ci font partie de notre audit d'automatisation.