Comprendre un logiciel fermé avant de le remplacer

L'essentiel à retenir

Remplacer un logiciel fermé sans comprendre son comportement réel, c’est migrer une entreprise sur la foi d’une documentation souvent incomplète. L’écran montre une partie du système. Les fichiers, les échanges réseau, les règles implicites et les cas d’erreur en racontent une autre. Pour une PME, l’objectif raisonnable n’est donc pas de « casser » le logiciel ni d’en copier le code. Il est de produire une carte vérifiable de ce que l’outil fait aujourd’hui, avant de décider ce que le futur système devra conserver, corriger ou abandonner.

REA fournit à un agent des moyens d’inspection pour plusieurs familles de cibles, dont les applications natives, JavaScript ou Electron, les assemblages .NET et les sites web. L’analyse peut rester locale, mais les résultats transmis à l’agent dépendent aussi de la politique de données de son fournisseur de modèle. Chaque conclusion doit rester attachée à une preuve, à une méthode et à une limite. Et aucune preuve technique ne crée, à elle seule, un droit d’analyse. Avant toute investigation, il faut établir ce que l’entreprise possède, ce qu’elle est autorisée à examiner et dans quelles conditions.

Le problème que ça résout

Une migration échoue rarement parce qu’une équipe a oublié le nom d’un bouton. Elle échoue lorsque personne ne sait précisément ce que ce bouton déclenche.

Dans une PME de 10 à 50 personnes, un logiciel métier peut avoir accumulé des années de règles non écrites. Une remise est calculée différemment pour certains dossiers. Un export exclut silencieusement un statut. Une synchronisation ne part qu’après une validation. Un fichier est renommé selon une convention connue d’une seule personne. La documentation décrit l’intention générale, pas nécessairement le comportement effectivement observé.

Le jour du remplacement, trois sources se contredisent alors : le manuel, les souvenirs des utilisateurs et le logiciel lui-même. Choisir arbitrairement l’une d’elles revient à déplacer l’incertitude dans le nouveau système. Elle réapparaîtra plus tard sous forme d’écarts de données, de procédures manuelles ou de décisions impossibles à expliquer.

Une analyse structurée sert à transformer ce flou en inventaire. Elle peut aider à répondre à des questions concrètes :

• Quels fichiers l’application lit-elle ou produit-elle ?
• Quels services contacte-t-elle pendant une opération précise ?
• Quelles validations sont visibles dans les composants inspectés ?
• Quel comportement apparaît seulement pendant l’exécution ?
• Quelles conclusions sont certaines, probables ou encore inconnues ?

Ce travail réduit la dépendance à une documentation incomplète. Il ne garantit pas une compréhension totale. Un binaire peut être obscurci, une fonction peut dépendre d’un serveur inaccessible, un comportement peut varier selon la configuration ou les données. La bonne sortie n’est donc pas un récit sûr de lui. C’est un dossier qui sépare les faits observés, les interprétations et les zones encore ouvertes.

Ce que c'est concrètement

REA est un ensemble d’outils reliés à un agent par MCP. L’agent formule une question, appelle les moyens d’inspection adaptés à la cible, reçoit des résultats accompagnés d’éléments de preuve, puis peut poursuivre l’enquête. Les mêmes familles de workflows peuvent aussi être utilisées depuis un terminal, mais l’intérêt pour une équipe métier tient surtout à la boucle : question, observation, preuve, nouvelle question.

Le projet couvre plusieurs niveaux d’analyse. L’analyse statique lit des fichiers sans lancer l’application. Selon le format, elle peut révéler des modules, des imports, des métadonnées, des chaînes de caractères, des instructions ou des relations entre composants. L’analyse à l’exécution observe ce qui se passe lorsque le programme tourne : sorties, interactions, accès à des fichiers, comportement d’un processus ou échanges visibles dans une capture autorisée.

Ces deux vues ne sont pas interchangeables. Le statique montre ce qui existe dans l’artefact examiné, pas nécessairement ce qui sera exécuté dans votre scénario. Le runtime montre ce qui s’est produit pendant une observation donnée, pas tout ce que le logiciel pourrait faire. Une conclusion solide indique donc la cible, la version, l’environnement, le scénario, la preuve et ce que la méthode ne permet pas d’affirmer.

Il faut aussi distinguer trois notions que les discussions techniques mélangent facilement.

La rétro-ingénierie est une démarche d’examen visant à comprendre un système à partir de ses artefacts ou de son comportement. La preuve technique est l’élément qui soutient une conclusion : référence, extrait, trace, fichier, comparaison ou observation reproductible. L’autorisation juridique détermine si cette démarche peut être menée sur cette cible, avec ces outils et dans ce contexte.

L’une ne remplace jamais l’autre. Un rapport très bien sourcé peut provenir d’une analyse non autorisée. À l’inverse, une autorisation claire ne rend pas automatiquement une conclusion technique correcte. Il faut les deux contrôles, chacun dans son rôle.

Enfin, « local » mérite une phrase entière. REA annonce une analyse locale des cibles. Cela limite certains transferts directs du logiciel inspecté. Mais si un agent envoie des résultats, des extraits ou du contexte à un modèle distant, le fournisseur de ce modèle applique sa propre politique de traitement des données. Avant d’utiliser l’outil sur des informations sensibles, l’entreprise doit comprendre cette chaîne complète, pas seulement l’endroit où tourne le moteur d’analyse.

Comment s'en servir

Étape 1 : cadrer la question avant de toucher au logiciel

Commencez par une fonction métier étroite. Par exemple : documenter ce qui se passe entre la validation d’un dossier et la création de son export. Une demande comme « comprendre toute l’application » produit surtout du bruit, des coûts et des conclusions difficiles à vérifier.

Écrivez le résultat attendu sous forme de faits à établir. Quels déclencheurs ? Quelles entrées ? Quelles sorties ? Quels cas d’erreur ? Quelles dépendances externes ? Cette liste deviendra le plan de preuve. Elle évite que l’agent transforme une exploration technique en visite guidée sans décision au bout.

Étape 2 : établir l’autorisation et les limites

Identifiez la cible exacte, son propriétaire, la licence applicable, les contrats concernés, les restrictions d’usage et les personnes habilitées à décider. Si le logiciel appartient à l’entreprise, vérifiez encore les droits attachés aux composants tiers et aux outils nécessaires. Si l’entreprise est seulement utilisatrice, ne déduisez pas une autorisation d’analyse du simple fait qu’elle peut ouvrir l’application.

Fixez aussi des limites opérationnelles : environnement isolé, données de test, comptes dédiés, interdiction de contourner une protection, absence d’accès aux données d’autrui et arrêt immédiat en cas de doute. Pour une situation ambiguë, faites valider le périmètre par un professionnel qualifié avant l’analyse. La technique peut prouver un comportement. Elle ne tranche pas la portée d’un contrat.

Étape 3 : préserver un point de départ reproductible

Conservez l’identification de la version étudiée, les fichiers fournis, leur provenance autorisée, la configuration utile et le scénario de test. Travaillez sur une copie contrôlée lorsque c’est permis et approprié. Évitez de lancer une investigation sur le poste quotidien d’un collaborateur ou sur un environnement de production sans préparation.

Le but est simple : permettre à une autre personne autorisée de comprendre ce qui a été examiné et, si nécessaire, de reproduire l’observation. Sans ce socle, une trace exacte peut tout de même mener à une conclusion fausse parce qu’elle se rapporte à une autre version ou à un paramétrage oublié.

Étape 4 : commencer par le statique

L’analyse statique donne une première carte sans exécuter la cible. Elle peut inventorier des composants, repérer des formats, identifier des dépendances ou faire ressortir des zones à examiner. Pour certaines applications JavaScript, Electron ou .NET, cette étape peut avancer sans moteur d’analyse native. D’autres cibles demandent un outil spécialisé déjà disponible et correctement licencié.

Ne demandez pas encore une explication globale. Demandez des réponses attachées à des références précises : quel composant semble gérer l’export, quelle donnée soutient cette hypothèse, quelle autre explication reste possible ? Une hypothèse utile ouvre le prochain test. Une certitude prématurée le ferme.

Étape 5 : observer le runtime avec un scénario borné

Quand le statique ne suffit pas, exécutez un scénario autorisé dans un environnement maîtrisé. Notez les actions de l’utilisateur, les entrées, les sorties et les effets constatés. Une capture réseau ou une observation de processus peut exposer des données sensibles ; son usage doit donc respecter le périmètre défini au départ.

Répétez le scénario en changeant une variable à la fois. Si le résultat varie, vous obtenez une piste. S’il ne varie pas, vous éliminez peut-être une hypothèse. Dans les deux cas, l’observation doit rester liée au contexte exact de l’essai. Un test n’est pas une loi universelle.

Étape 6 : construire une matrice de preuves

Pour chaque comportement important, consignez la question, la conclusion provisoire, la preuve, la méthode, le niveau de confiance et la limite. Ajoutez le prochain test nécessaire lorsque la conclusion reste incertaine.

Cette matrice devient plus utile qu’un long rapport narratif. Elle permet au responsable métier de contester une interprétation, au développeur de retrouver la trace et au décideur de distinguer une exigence confirmée d’une supposition. Elle protège aussi le projet contre un travers fréquent des agents : une formulation fluide peut masquer une preuve faible.

Étape 7 : transformer les constats en contrat de migration

Le livrable final n’est pas une copie du logiciel. C’est une description testable de ce que le remplacement doit gérer. Classez les comportements en quatre catégories : à conserver, à corriger, à supprimer délibérément ou à arbitrer.

Associez ensuite chaque exigence à un test d’acceptation et à sa preuve d’origine. Lorsque le nouveau système produit un résultat différent, l’équipe peut enfin poser la bonne question : régression, amélioration voulue ou ancien comportement mal compris ? La migration cesse d’être une imitation de l’écran. Elle devient une décision documentée.

Ce que ça coûte vraiment

Le logiciel peut être accessible, mais l’enquête n’est pas gratuite. Son coût principal vient du temps d’intégration, de la préparation des environnements, de la revue des preuves et des compétences nécessaires pour interpréter les résultats.

Certaines analyses peuvent s’appuyer sur des capacités intégrées. D’autres exigent des moteurs externes, des outils commerciaux ou des composants à installer. REA ne fournit pas les licences de ces outils. Une entreprise doit donc vérifier les conditions d’utilisation, les droits d’automatisation, les restrictions éventuelles sur les sorties et la compatibilité avec son environnement. Posséder un abonnement ne signifie pas que tous les usages automatisés sont permis.

Il faut aussi budgéter la sécurité. Isoler une cible, retirer des données réelles, préparer des scénarios, stocker les traces et contrôler ce qui part vers le fournisseur de modèle prennent du temps. Ce temps n’est pas un détour administratif. Il évite qu’une migration destinée à réduire une dépendance crée une nouvelle exposition de données ou une dépendance à des conclusions impossibles à reproduire.

Le dernier coût est humain. Un agent accélère la collecte et relie des indices, mais quelqu’un doit définir la question métier, vérifier les preuves et accepter les limites. Si personne dans l’équipe ne peut distinguer une chaîne trouvée dans un fichier d’un comportement réellement exécuté, l’outil risque de produire beaucoup de matière et peu de connaissance.

Le bon calcul ne compare donc pas « outil gratuit » et « consultant coûteux ». Il compare le coût d’une enquête bornée au coût d’une migration menée à l’aveugle. Plus le logiciel est central, ancien ou mal documenté, plus la preuve en amont peut éviter des arbitrages tardifs. Sans inventer de retour sur investissement : on mesure le nombre d’inconnues levées, la reproductibilité des constats et les exigences de migration désormais testables.

Pour qui ce n'est pas

REA n’est pas adapté lorsque l’entreprise n’a pas établi son autorisation d’examiner la cible. Le doute juridique n’est pas une invitation à « tester vite ». C’est un signal d’arrêt.

Ce n’est pas non plus le bon premier choix si l’éditeur fournit une documentation à jour, des interfaces d’export fiables et un accompagnement de migration suffisant. L’inspection technique doit répondre à une lacune réelle, pas devenir un rituel parce que l’outil existe.

Évitez aussi cette approche lorsque la cible ne peut pas être isolée, lorsque l’observation risque d’affecter la production ou lorsque les données visibles sont trop sensibles pour le dispositif retenu. Une analyse locale n’annule pas la politique du fournisseur de modèle, ni les risques liés aux journaux, aux captures et aux fichiers intermédiaires.

Enfin, l’outil ne convient pas à une équipe qui cherche une réponse définitive sans organiser la contradiction. Une sortie d’agent n’est pas un verdict. Une trace n’explique pas toujours la cause. Un pseudocode n’est pas le code source original. Une observation runtime ne couvre pas tous les chemins possibles.

Si vous ne pouvez pas conserver les preuves, refaire les tests ou faire relire les conclusions, mieux vaut revenir à une méthode plus simple : entretiens utilisateurs, export contrôlé, tests fonctionnels manuels et collaboration avec l’éditeur. La sophistication technique n’a de valeur que si elle réduit l’incertitude.

Source : https://github.com/morluto/rea

FAQ

Peut-on analyser un logiciel simplement parce que l’entreprise l’utilise ?

Non, l’usage ne suffit pas à démontrer l’autorisation d’analyse. Il faut examiner les droits de l’entreprise, la licence, les contrats, la cible précise et la méthode envisagée. En cas de doute, le périmètre doit être validé avant toute investigation.

Quelle différence entre analyse statique et observation runtime ?

L’analyse statique inspecte les artefacts sans lancer l’application. L’observation runtime étudie ce qui se produit pendant une exécution donnée. La première révèle des éléments présents ; la seconde confirme certains comportements dans un scénario précis. Les deux ont des angles morts.

Une preuve technique suffit-elle pour définir une exigence de migration ?

Elle fournit une base, pas la décision complète. L’équipe doit vérifier que la preuve concerne la bonne version et le bon contexte, puis décider si le comportement doit être conservé, corrigé ou supprimé dans le futur système.

Les données restent-elles entièrement locales avec REA ?

La cible est analysée localement selon la documentation du projet. Cependant, les résultats transmis à l’agent peuvent être traités par le fournisseur de son modèle selon sa propre politique. Il faut donc examiner toute la chaîne de données avant d’utiliser des informations sensibles.

Faut-il un outil propriétaire pour commencer ?

Pas pour toutes les cibles. Certaines inspections statiques sont disponibles sans moteur natif spécialisé. L’analyse native approfondie peut en revanche dépendre d’outils externes, avec leurs prérequis techniques et leurs licences propres.

Quel livrable demander avant le remplacement ?

Demandez une matrice des comportements qui relie chaque conclusion à sa preuve, sa méthode, son niveau de confiance, ses limites et un test d’acceptation. Ce format rend les désaccords visibles et transforme les constats en décisions de migration vérifiables.

---

Publié le 24 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.