Rétro-ingénierie de boîte noire

SECTION 1

Introduction

C'est un scénario qui fait frissonner tout CTO : une application critique pour l'entreprise est en fonctionnement, mais le code source a disparu. Peut-être qu'une relation avec un fournisseur s'est détériorée, vous laissant avec un binaire fonctionnel mais opaque. Ou imaginez que vous avez accès au code source, mais il est tellement désordonné que les humains et l'IA ont du mal à comprendre et à décrire ce que le codebase fait réellement.

Généralement, l'une de nos approches pour accélérer la modernisation des systèmes existants avec l'IA consiste à l'utiliser pour accélérer d'abord la partie rétro-ingénierie, alimenter l'IA avec le code existant, puis la laisser nous aider à créer une description complète de la fonctionnalité de l'application, qui peut être utilisée dans l'ingénierie directe.

Mais que se passe-t-il si nous n'avons pas le code, ou s'il est tellement désordonné qu'il est inutilisable ? Comment l'IA générative peut-elle accélérer la rétro-ingénierie dans ce cas ?

Récemment, nous avons exploré cette question chez Adservio : le résultat était une expérience de « rétro-ingénierie de boîte noire ». Nous avons voulu découvrir si, en combinant la navigation pilotée par IA avec des techniques de capture de données, nous pouvions créer une spécification fonctionnelle détaillée d'un système existant et l'utiliser pour construire un remplaçant moderne à partir de zéro.

Ceci est l'histoire de comment nous l'avons fait, les obstacles que nous avons rencontrés et les leçons puissantes que nous avons apprises sur l'avenir de la modernisation des systèmes existants.

SECTION 2

Configuration de notre expérience IA

Comme sujet de test, nous avons choisi Odoo, une plateforme ERP open-source facile à configurer et exécuter sur nos machines. Le code back-end de l'application était strictement interdit à notre configuration IA, nos sources d'informations étaient limitées à ce qui pouvait être observé de l'extérieur :

L'interface utilisateur. L'IA pouvait voir et interagir avec l'application exactement comme un utilisateur le ferait, en observant les éléments statiques, les comportements dynamiques et les chemins de clic. La base de données. Bien que le code back-end soit caché, le schéma et les données existantes étaient autorisés. Le trafic réseau. Nous avons également permis à l'IA d'inspecter les requêtes réseau s'écoulant du navigateur vers le serveur back-end comme source de données supplémentaire.

La portée de notre expérience était de :

Effectuer une rétro-ingénierie de la fonctionnalité d'un parcours utilisateur unique et fondamental : créer une nouvelle opportunité dans le pipeline commercial du CRM d'Odoo. Le livrable de cette étape était un document de spécification décrivant toutes les informations disponibles sur le comportement de l'application, y compris les captures d'écran. Explorer les nouvelles opportunités que l'IA générative offre pour construire un « test de parité fonctionnelle » qui peut être exécuté contre l'ancienne application et la nouvelle.

SECTION 3

Itération expérimentale un : Reconnaissance

Notre première tentative était une exploration large.

### L'IA en tant qu'utilisateur

Nous avons envoyé un agent IA avec accès au serveur MCP Playwright pour naviguer dans l'application. L'invite lui demandait de « découvrir le parcours utilisateur pour créer une nouvelle opportunité dans le pipeline commercial ». L'agent a cliqué dans l'interface utilisateur, a pris des captures d'écran et a généré une description de tous les dialogues avec leurs champs et les comportements dynamiques qu'il pouvait observer (par exemple « lorsqu'une entrée est choisie dans cette liste déroulante, les champs du formulaire sont remplis automatiquement »). Nous avons également demandé un organigramme décrivant le chemin de clic qu'il a trouvé. Le flux qu'il a trouvé était un chemin très linéaire « heureux », presque étrangement simple. Aucune application du monde réel n'est si directe ; nous savions qu'il y avait plus de travail à faire pour que l'IA découvre la réalité plus complexe des chemins.

### Capture des données de changement

Après avoir eu une première description des chemins, nous avons demandé à l'IA de naviguer à nouveau et de consulter les modifications de la base de données après chaque clic. Cela a été rendu possible en configurant des déclencheurs dans la base de données qui ont créé un journal de chaque opération INSERT et UPDATE dans l'une des tables pertinentes. Nous avons construit un petit serveur MCP personnalisé qui permettait à l'agent IA de interroger ce journal d'audit après chaque interaction. En conséquence, notre spécification fonctionnelle a été enrichie des opérations de base de données qui se sont produites après chaque étape de clic. Cette approche de capture des données de changement (CDC) s'est avérée être un moyen puissant et peu coûteux de décortiquer les requêtes de l'extérieur.

@cite:le-protocole-model-context-au-dela-de-la-tendance

SECTION 4

Itération expérimentale deux : Affinage de la spécification

### Multiplier les exécutions pour converger vers un flux fiable

Avec les informations de notre première tentative, nous avons amélioré le flux de travail et les invites. D'abord, nous avons affiné notre invite de découverte des chemins de clic, en la demandant plus explicitement de trouver et de traverser toutes les actions utilisateur possibles sur chaque écran. Et, au lieu d'une seule exécution, nous avons exécuté l'agent plusieurs fois, car nous supposions que l'IA aurait du mal à trouver toutes les branches de chemin en une seule exécution. Nous avions raison : chaque exécution a découvert des branches et des variations légèrement différentes.

Nous avons ensuite utilisé une autre étape IA pour « converger » ces différentes versions, analyser et vérifier les divergences et créer une seule carte consolidée du flux utilisateur. Les diagrammes résultants étaient bien plus représentatifs du comportement réel de l'application.

### Tentative de rétro-ingénierie du trafic réseau

Dans cette itération, nous avons également tenté d'ajouter une autre couche de collecte de données en capturant le trafic réseau. L'idée était d'effectuer une rétro-ingénierie de l'API back-end en analysant les charges JSON passant entre le front-end et le back-end.

Bien que nous ayons finalement réussi à générer un document Swagger de l'API, cette configuration était bien plus difficile à comprendre que la capture des données de changement.

Nous avons également conclu que pour ce scénario spécifique, où l'API est un détail d'implémentation interne, pas un contrat public, les informations sur l'API back-end ne nous ont vraiment rien donné de nouveau que nous ne savions déjà sur les structures de données.

### Validation par la reconstruction

Le test ultime était d'utiliser nos artefacts générés par IA pour créer une nouvelle application. Notre objectif dans cette expérience n'était pas l'ingénierie directe, donc nous ne voulions pas passer trop de temps sur cette étape.

Cependant, nous avions toujours besoin de vérifier si la spécification était utile ; nous avons donc décidé de l'alimenter dans l'un des outils de génération rapide d'applications IA.

Premièrement, nous avons alimenté notre spécification détaillée, la collection de fichiers Markdown, de captures d'écran et de descriptions de logique de base de données, dans une série d'invites qui ont généré des épopées, des histoires utilisateur et un ordre de mise en œuvre. Ensuite, nous avons alimenté le premier ensemble d'histoires dans Replit.

Voici quelques observations de cette phase de validation :

Prototypage en tant que validateur. Regarder l'IA construire le prototype était un moyen très efficace de valider et d'améliorer la spécification. Lorsque le prototype s'écartait de l'original, il était parfois plus facile de repérer un défaut ou une ambiguïté dans notre document de spécifications que lors de la lecture de la spécification. L'IA lutte dans la planification. Les LLM ont souvent du mal à créer un plan de mise en œuvre logique et progressif ; c'était le cas ici. Son instinct initial était de construire toute la vue de pipeline complexe d'un coup, plutôt que de commencer par les éléments les plus simples et de construire progressivement. Un bon flux de travail IA et une supervision humaine sont importants pour guider la stratégie de construction dans un scénario réel. Aucune démonstration de fidélité des requêtes. Malheureusement, Replit a ignoré nos entrées sur le schéma de la base de données et les requêtes exactes que nous souhaitions effectuer. Comme nous ne voulions pas passer trop de temps avec l'ingénierie directe, cela signifiait que nous ne pouvions pas montrer pleinement que la nouvelle application pouvait être dirigée vers la base de données existante. Cependant, l'IA générative est généralement très douée pour récupérer des exemples et des schémas spécifiques et les utiliser dans le code ; ce n'est pas un grand pas de penser que les requêtes de base de données spécifiques que nous avons collectées pourraient être reproduites par un agent de codage avec des invites dédiées.

SECTION 5

L'IA peut-elle aider à tester la parité ?

Bien que l'application générée ne soit pas parfaite, elle nous a fourni l'occasion de mener une deuxième expérience : Comment pourrions-nous créer une suite de tests automatisée qui pourrait s'exécuter contre l'ancienne application et notre nouveau prototype légèrement différent ?

Le défi est que, bien que nous nous attendions aux mêmes contrôles généraux de l'utilisateur, la nouvelle application pourrait avoir un aspect légèrement différent, et aura certainement des sélecteurs DOM différents. L'IA offre certaines opportunités ici pour rendre les instructions d'interface utilisateur plus vagues, ce qui est un avantage dans ce cas d'utilisation. Elle peut utiliser les visuels comme information et réagir à des descriptions d'éléments d'interface utilisateur plus vagues. Par exemple, vous pourriez dire des choses comme « cherchez une icône + », et cela pourrait fonctionner, que ce soit implémenté avec une icône image ou une représentation textuelle.

Nous avons utilisé un framework qui vous permet d'ajouter des instructions de test en langage naturel à un test Playwright. Au lieu d'écrire un sélecteur comme find('button#id-123'), nous pourrions alors faire des instructions comme await ai('Click the + icon to create a new opportunity'). De cette façon, le test n'était pas lié à une structure DOM spécifique, ce qui signifiait qu'il était suffisamment haut niveau pour s'exécuter contre deux implémentations différentes de la même interface utilisateur.

Lorsque nous avons construit une suite de tests qui s'exécutait contre les deux applications, nous nous sommes surtout heurtés à des problèmes typiques de test de navigateur de bout en bout, comme l'ajout de temps d'attente. Ajouter le non-déterminisme de l'IA au-dessus de la notoriété instabilité de ces tests crée une nouvelle série de défis. Ceci est un cas d'utilisation prometteur, mais qui nécessite une implémentation soigneuse pour éviter plus de bruit que de signal.

Prérequis et limitations, Cette approche repose sur la disponibilité d'un environnement de test sûr et isolé où les agents IA peuvent explorer librement et où les scripts de capture de données peuvent être exécutés sans impact sur les opérations en direct.

Selon le type et la complexité de l'application, nous nous attendre à ce que le document de spécification rétro-conçu résultant ait des niveaux d'écarts variant qui nécessiteraient des contributions d'experts en la matière, comme s'il y a une logique plus complexe qui n'est pas observable dans une interface utilisateur. Nous n'avons pas non plus exploré les techniques pour les paysages impliquant la communication de service à service ou d'autres effets côté back-end. Une capture de données réseau plus approfondie pourrait être utile ici.

SECTION 6

Conclusions et points clés

Notre expérience nous a montré qu'il existe un grand potentiel dans l'utilisation de l'IA pour effectuer une rétro-ingénierie d'une application sans avoir accès à son code source.

Voici trois points clés à retenir :

L'IA est un accélérateur, pas un automatiseur. Un thème récurrent dans toutes nos expériences est que, bien que l'IA soit un multiplicateur de force puissant, elle ne remplace pas l'expertise humaine. Elle réalise la première tentative, génère la documentation de base et libère les experts en la matière pour qu'ils se concentrent sur le raffinement et la validation. Le processus est une collaboration humain-IA.. Itérer et décomposer. Diviser l'application en parcours utilisateur et le processus de rétro-ingénierie en petites étapes itératives (découvrir, converger, ajouter des détails) aide à obtenir des résultats de plus haute fidélité. Valider en continu. L'utilisation de techniques telles que le prototypage rapide et les tests de parité vous permet de créer des boucles de rétroaction précoces.

@cite:de-la-boite-noire-au-plan-technique-comment-nous-avons

Clause de non-responsabilité : Les déclarations et opinions exprimées dans cet article sont celles de l'auteur(s) et ne reflètent pas nécessairement les positions d'Adservio.

FAQ

Questions fréquentes