les questions qui me viennent naturellement sont qu'ils me manquent un § d'introduction ;-)
Là on rentre directement dans le sujet (et j'ai trouvé cela plutôt agréable à lire, plus ci-dessous).
bref, un article d'intro pour le contexte m'aurait aidé, avant de devoir mettre les mains dans le cambouis directement ;-)
J'y verrais les thèmes suivants.
pourquoi le choix de Haskell ? En quoi est-il bien — voire mieux — adapté à la rétro-ingénierie ? Quels auraient été tes autres choix ?
à mon grand étonnement, le code haskell est bien lisible (je ne pratique pas :D) même si ajouter des commentaires dans le code pourrait être utile pour rentrer dans la logique de son découpage : objet des fonctions (entrées et sorties attendues selon les cas), pourquoi certaines fonctions sont ressorties ? (réutilisation ? facilitation lecture ? généricité ?). Même si tu donnes le contexte autour (ce qui m'a beaucoup facilité la lecture du code), j'ai tendance à attendre que le code ait le minimum de commentaires permettant de comprendre à quoi il sert et ce qu'il produit.
bravo pour les références à ECMA-119, au moins c'est normatif et raccroché à quelque chose de concret ;-) (et un peu indispensable)
donc l'objet de ta série d'article est de corroborer en quoi les fichiers à ta disposition sont conformes à ECMA-119 ? ou d'identifier des écarts et leur trouver une justification (et exhaustivité des cas rencontrés) ?
ça manque un peu d'un rappel des limites que tu te donnes pour publication, même si cela transparaît dans tes formulations, notamment « implémenter la plus petite capacité nécessaire à l’étape suivante ». Rappeler (plutôt dans un article dédié) les « zones grises » me paraît important. Notamment le fait que tu te confrontes à des CLUF non adaptés au droit européen dans lequel il est par exemple illégal de prétendre que la décompilation est illégale (cela fait des clauses léonines dans ces contrats, trop longs à lire de toute façon et non rédigés pour être compréhensibles par le commun des mortels...). Ce qui est légal en Europe, c'est la rétro-ingénierie à des fins d'interopérabilité, justement le cas qui te concerne avec des fichiers censés respecter des normes et pouvoir être a minima relus par d'autres logiciels en lien avec tout ce qui est format ouvert. Comme dans beaucoup d'autres pays, tu n'as en revanche par défaut pas le droit de publier tel quel le produit d'une décompilation (hormis licence libre du fichier d'origine, par exemple). J'imagine que les autres outils auquel tu fais allusion ont un § similaire (plus ou moins développé, autant reprendre ce qui s'applique à ton cas).
bref, il y a de quoi peupler tout un article, et tu aurais intérêt à le garder sous le coude pour tracer au fur et à mesure les choix de ce que tu publies et ce que tu conserves pour toi.
typiquement, il serait intéressant d'avoir des fichiers d'exemple — sous une licence acceptable permettant un minimum de republication (voire une publication sans limitation, on peut rêver, même si la licence MIT est intéressante pour cela :p) — rien que pour que chaque utilisateur puisse valider le bon fonctionnement de ton outil de leur côté ou mettre en place une chaîne de CI. Et bien sûr, ce ne sera sans doute pas les fichier d'origine :/ Mais cela donnerait les indications à ceux qui l'appliqueraient à leurs fichiers à disposition ce qu'ils peuvent se permettre de publier et ce qu'ils doivent garder pour eux.
sinon, petite remarque : tu as conservé le terme offset non traduit — à raison àmha — autant réutiliser le terme du domaine lorsqu'il est approprié (plutôt qu'une traduction bancale), cela facilite la lecture des articles en anglais, d'autant que lorsque tu choisis une traduction tu donnes la référence des termes d'origine.
voilà pour des remarques générales à première lecture, il n'y a pas vraiment de points spécifiques qui m'ont gêné lors de cette lecture ;-) bravo pour le style.
# intro
Posté par BAud (site web personnel) . En réponse au journal D’une image nommée .iso à un premier probe en Haskell. Évalué à 4 (+2/-0). Dernière modification le 03 septembre 2026 à 12:34.
les questions qui me viennent naturellement sont qu'ils me manquent un § d'introduction ;-)
Là on rentre directement dans le sujet (et j'ai trouvé cela plutôt agréable à lire, plus ci-dessous).
bref, un article d'intro pour le contexte m'aurait aidé, avant de devoir mettre les mains dans le cambouis directement ;-)
J'y verrais les thèmes suivants.
pourquoi le choix de Haskell ? En quoi est-il bien — voire mieux — adapté à la rétro-ingénierie ? Quels auraient été tes autres choix ?
à mon grand étonnement, le code haskell est bien lisible (je ne pratique pas :D) même si ajouter des commentaires dans le code pourrait être utile pour rentrer dans la logique de son découpage : objet des fonctions (entrées et sorties attendues selon les cas), pourquoi certaines fonctions sont ressorties ? (réutilisation ? facilitation lecture ? généricité ?). Même si tu donnes le contexte autour (ce qui m'a beaucoup facilité la lecture du code), j'ai tendance à attendre que le code ait le minimum de commentaires permettant de comprendre à quoi il sert et ce qu'il produit.
bravo pour les références à ECMA-119, au moins c'est normatif et raccroché à quelque chose de concret ;-) (et un peu indispensable)
donc l'objet de ta série d'article est de corroborer en quoi les fichiers à ta disposition sont conformes à ECMA-119 ? ou d'identifier des écarts et leur trouver une justification (et exhaustivité des cas rencontrés) ?
ça manque un peu d'un rappel des limites que tu te donnes pour publication, même si cela transparaît dans tes formulations, notamment « implémenter la plus petite capacité nécessaire à l’étape suivante ». Rappeler (plutôt dans un article dédié) les « zones grises » me paraît important. Notamment le fait que tu te confrontes à des CLUF non adaptés au droit européen dans lequel il est par exemple illégal de prétendre que la décompilation est illégale (cela fait des clauses léonines dans ces contrats, trop longs à lire de toute façon et non rédigés pour être compréhensibles par le commun des mortels...). Ce qui est légal en Europe, c'est la rétro-ingénierie à des fins d'interopérabilité, justement le cas qui te concerne avec des fichiers censés respecter des normes et pouvoir être a minima relus par d'autres logiciels en lien avec tout ce qui est format ouvert. Comme dans beaucoup d'autres pays, tu n'as en revanche par défaut pas le droit de publier tel quel le produit d'une décompilation (hormis licence libre du fichier d'origine, par exemple). J'imagine que les autres outils auquel tu fais allusion ont un § similaire (plus ou moins développé, autant reprendre ce qui s'applique à ton cas).
bref, il y a de quoi peupler tout un article, et tu aurais intérêt à le garder sous le coude pour tracer au fur et à mesure les choix de ce que tu publies et ce que tu conserves pour toi.
typiquement, il serait intéressant d'avoir des fichiers d'exemple — sous une licence acceptable permettant un minimum de republication (voire une publication sans limitation, on peut rêver, même si la licence MIT est intéressante pour cela :p) — rien que pour que chaque utilisateur puisse valider le bon fonctionnement de ton outil de leur côté ou mettre en place une chaîne de CI. Et bien sûr, ce ne sera sans doute pas les fichier d'origine :/ Mais cela donnerait les indications à ceux qui l'appliqueraient à leurs fichiers à disposition ce qu'ils peuvent se permettre de publier et ce qu'ils doivent garder pour eux.
sinon, petite remarque : tu as conservé le terme offset non traduit — à raison àmha — autant réutiliser le terme du domaine lorsqu'il est approprié (plutôt qu'une traduction bancale), cela facilite la lecture des articles en anglais, d'autant que lorsque tu choisis une traduction tu donnes la référence des termes d'origine.
voilà pour des remarques générales à première lecture, il n'y a pas vraiment de points spécifiques qui m'ont gêné lors de cette lecture ;-) bravo pour le style.