[TRAD2012] Synthèse sur les outils de traduction automatique de code

Voici déjà venu l’heure de notre dernier article de synthèse.

Lorsque nous avons commencé cette veille technologique, nous avons été surpris par la quantité de projets de traduction de code existants. Il est vrai que la traduction de langage a de nombreux intérêts qui vont de la portabilité du code, à l’amélioration de performance en passant par l’accélération du redéveloppement d’un outil ou simplement pour limiter le nombre de langage à maîtriser. Beaucoup se sont donc lancés dans l’aventure et ont cherché à développer des outils de traduction automatique de code, mais pour toutes les raisons que nous avons pu évoquer, la plupart n’ont pas dépassé le stade de projet.

Ainsi, contrairement à ce que nous vous avions annoncé, nous n’avons pas comparé pour vous les différents outils de traduction existants. Nous avons préféré vous fournir une liste des outils les plus avancés. Nous vous avons aussi présenté la façon dont fonctionnent ces outils et quelles méthodes ils utilisent pour que vous sachiez ce que vous utilisez si vous vous lancez dans la traduction automatisée de code. Un petit conseil cependant, si des traducteurs comme J2ObjC ou des outils pouvant faire de la compilation croisée comme LLVM existent, le code produit n’est jamais d’une qualité irréprochable et peut être difficile à corriger. A vous de voir si un traducteur de code vous est indispensable ou s’il existe des manières alternatives qui ne vous obligeraient pas à maintenir votre code en plusieurs langages. Et pensez à des architectures orientées modèles avant de vous lancer dans un projet dont vous savez à l’avance qu’il devra être traduit ou migré sous plusieurs plateformes.

Vous avez déjà du comprendre qu’en dehors de quelques projets bien particuliers, il y a peu d’actualités dans le monde des outils de traduction, certains étant quasiment à l’état d’abandon. Notre projet de veille à surtout été un projet de recherche, mais nous tenons néanmoins à vous signaler les quelques changements. Il y a eu de petites mises à jour de ROSE et de nouvelles versions mineures de Vala et de Pyjs. Du côté de J2ObjC, une nouvelle version est sortie le mois dernier et il y a régulièrement de petites corrections et de petits ajouts. Et il ne faut pas oublier la conférence LLVM qui aura lieu fin Avril à Paris, mais il n’y a aucun moyen de savoir si des améliorations du compilateur croisé seront envisagées.

Il ne nous reste plus qu’à vous donner notre rapport, dont le plan et le téléchargement sont disponibles plus bas, et à vous souhaiter bonne chance dans vos projets de développement.

  • Les intérêts de la traduction
    • La portabilité
    • La performance
    • La maintenabilité
  • Les difficultés de la traduction
  • Les méthodes de la traduction
    • La chaîne de compilation
    • Les transformations sur les arbres
    • Des transformations préalables
  • Les différents outils que nous avons trouvé
    • Les mastodontes…
    • Et les autres
  • Vers une autre approche : l’anticipation et l’approche modèle

Vous pouvez télécharger notre rapport ici : pvete12_rapport_trad2012

Sébastien Malkowiak, Yohann Facon

[TRAD2012] MDA, un outil de transformation de modèle

Nous nous sommes concentrés jusque ici à la traduction de langage à partir de code source. L’un des intérêts principaux est la portabilité du code. Néanmoins, il peut paraître pertinent d’anticiper cette traduction. En effet, aujourd’hui le codage n’est plus une étape obscure : on préfère généralement esquisser un modèle représentant l’implémentation du code avant de réellement écrire ces lignes de code. Une idée est donc d’opérer des transformations sur ces modèles eux mêmes permettant par la suite de convertir ensuite en un langage défini.

C’est l’idée qu’a eu l’organisme Object Management Group. Ils ont pensé un système de définition de modèles permettant de définir des modèles génériques appelé Model Driven Architecture, ou MDA pour architecture orienté modèles. Grâce à ces modèles génériques, on peut par la suite effectuer des transformations successives permettant d’aboutir à une génération de code pouvant tourner sur différentes plate-formes. qui peuvent être transformés par la suite en modèle spécifique à un langage propre.

Cela est rendu possible à l’aide de plusieurs représentations de modèle et à la définition d’aides à la transformation de modèle. Détaillons ce processus.

Utilisation d’un CIM (computing independant model) : La première étape consiste à définir ce que va réaliser le programme. On ne rentre pas dans le détail des opérations et surtout doit rester très générique.

Puis on définit un PIM (plateform independant model) qui décrit de manière un peu plus précise le modèle à décrire mais reste encore indépendant de toute plateforme. C’est à l’étape suivante que l’on définit les plateformes pouvant accueillir le programme.

Il est important par la suite de réaliser du mapping : dans certains rares cas il n’y aura aucune informations supplémentaires pour pouvoir réaliser le modèle cible mais la plupart du temps il faudra réaliser un mapping permettant de faire un lien entre différents entités des deux modèles. Il existe différents types de mapping tels que la correspondance de types ou d’autres caractéristiques plus spécifiques.

En réalité, il peut y avoir plusieurs mappings pour un seul modèle dans son ensemble. De ce fait on a besoin de marquer le modèle à transformer (PIM) pour savoir quel élément de mapping choisir pour les différentes parties du PIM. On appelle cela le marquage du modèle.
Une fois le marquage établi, on peut enfin réaliser la transformation du modèle vers le PSM (plateform specified model) qui est donc quant à elle bien particulière au langage cible. Cela peut être la représentation du code tel qu’il va être finalement implémenté ou réellement le code lui-même, cela dépend des cas.

Sources : OMG et le MDA, un peu de théorie (langue anglaise)

Sébastien Malkowiak, Yohann Facon

[TRAD2012] La méthodologie de traduction de code

Maintenant que nous avons parlé des outils de traduction de code, il est temps d’expliquer comment ils fonctionnent.

Nous avons vu lors de notre deuxième article qu’il existe de nombreux types de programmes manipulant du code, le plus important étant les compilateurs. Alors pour vous expliquer comment le code source d’un programme peut être traduit en un autre langage, nous allons devoir vous parler de compilateurs et de compilation.

La chaîne de compilation classique

Pour comprendre du code, un compilateur doit d’abord l’analyser et le décomposer. Il génère ainsi un langage intermédiaire, en faisant en sorte de perdre le moins d’informations possible par rapport au langage source. Cette première étape est la phase frontale. L’autre étape est la transformation de ce code intermédiaire en code objet (ou code machine), c’est la phase finale. Dans la plupart des compilateurs modernes, il existe aussi une phase intermédiaire qui effectue des transformations et des optimisations plus ou moins importantes sur le code intermédiaire.

Voici les différentes étapes de la chaîne de compilation :

Chaîne de compilation

L’analyse lexicale découpe le code source en terminaux syntaxiques, aussi appelés lexèmes, jetons (token) ou simplement mots. L’ensemble de ces mots est généralement défini par un langage régulier et peut donc être reconnu par des automates d’états finis.

L’analyse syntaxique vérifie le bon ordonnancement des mots et il construit l’arbre syntaxique abstrait (AST : Abstract Syntax Tree) dont les noeuds sont les opérations et les feuilles les opérandes.

L’analyse sémantique va ensuite annoter l’AST pour ajouter des informations sémantiques contextuelles. Cela comprend les types des opérandes, leur initialisation et en règle générale toutes les informations dont on a besoin. Cette analyse construit aussi la table des symboles.

La génération du code intermédiaire génère du code qui est idéalement indépendante du langage cible. Ce dernier est généralement un langage machine pour un compilateur.

Dans un compilateur classique, ce code intermédiaire est ensuite optimisé puis transformé en code objet. Cette génération de code est idéalement indépendante du langage source pour permettre la compilation de et/ou vers plusieurs langages. Mais un traducteur va rarement aussi loin dans la chaîne de compilation.

La traduction

Avec une bonne dose de chance, il existe, ou il est possible de créer, un compilateur dont langage intermédiaire est directement le langage cible. Cela arrive lorsque le langage source est assez proche du langage cible (C++ vers C) et qu’on sait générer le langage cible directement à partir de l’AST généré par l’analyse sémantique. Certains compilateurs passent par plusieurs langages intermédiaires car cela permet d’utiliser les compilateurs déjà existant de ces langages, efficaces on l’espère, sans avoir à développer le sien pour chacun des systèmes que l’on souhaite atteindre.

Ou alors on compte utiliser un autre outil qui sait traduire ce langage intermédiaire vers le langage cible. Mais de trop nombreuses étapes peuvent nuire à la qualité finale du code car en pratique on perd des informations presque à chacune de ces étapes.

Le cas général est aussi le plus compliqué puisque qu’il faut remonter les différentes étapes de la compilation et générer le code du langage cible à partir de l’AST. Cette étape devient vite un travail titanesque si les langages source et cible sont très différents car les modifications de l’AST nécessaires pour correspondre au langage cible peuvent être nombreuses, complexes et parfois même impossibles. C’est l’extrême difficulté de cette étape qui fait qu’il existe si peu de traducteurs automatiques de code, et qu’aucun n’est parfait ni même complet.

Sources : Cours de compilation à Centrale Nantes par Didier Lime, cours de compilation très détaillé, Image

Sébastien Malkowiak, Yohann Facon

[TRAD2012] Des projets de plus grande taille

Nous allons d’abord commencer par un outil qui peut être utile que nous avons découvert depuis le dernier article.

NestedVM

NestedVM permet de générer du Bytecode Java à partir de code binaire MIPS compilé par GCC. S’il ne permet pas d’obtenir du code Java, il peut traduire tout langage compilé par GCC (C, C++, Fortran…) en fichiers .class qui peuvent être exécuté par la JVM (Java Virtual Machine).

Outre les outils que nous vous avons présentés jusqu’à présent. il existe aussi quelques projets de taille bien plus importante. Ce type de projet voit le jour lorsque les enjeux sont suffisamment importants pour que les moyens nécessaires soient mis en oeuvre.

J2objC

Java to Objective-C, ou J2ObjC pour faire plus court, est une application open source qui permet de traduire du code Java en code Objective-C. C’est un outil plutôt complet et très bien documenté qui nous vient directement de Google.

Créer un traducteur de code est une tache longue et complexe mais Google avait une bonne raison de se lancer dans un projet de cette envergure. En effet, l’objectif est d’attirer vers Android les développeurs qui hésitent encore entre la plateforme de Google et celle d’Apple. L’autre utilité est que des développeurs Java peuvent maintenant cibler MacOS et iOS sans avoir à apprendre l’Objective-C.

Nous avons vu qu’une des nombres difficultés à surmonter pour traduire du code était le garbage collector. En effet si Android en possède un, ce n’est pas le cas sous iOS. J2ObjC propose donc 3 méthodes. La première, choisit pas défaut, est la méthode par comptage de référence qui est généralement utilisé en Objective-C sous iOS. La deuxième utilise la fonctionnalité d’Automatic Resource Counting (ARC) supporté depuis iOS 4 et Xcode 4.2 qui automatise en fait la première méthode. La troisième méthode est simplement d’utiliser le garbage collector de MacOS, mais cela ne fonctionnera évidemment pas sous iOS.

Mais cet outil ne fait pas tout. En effet J2ObjC ne prend pas en compte l’interface graphique qui est bien trop différente entre Android et iOS. Seules les classes Java, et donc la logique de l’application, sont donc traduites en classes Objective-C et il faut refaire une interface iOS de la manière classique (généralement Xcode).

J2ObjC prend en charge Java 6 et la plupart des fonctions les plus utilisées par des applications client : les exceptions, les classes internes et anonymes, les files, etc. Même la conversion et l’exécution des tests JUnit sont prises en charge. La liste complète est disponible sur le wiki officiel

Pour voir un exemple (simple) de code traduit par J2ObjC, voici un article qui prend en exemple un Hello World.

La version actuelle est la 0.5.6 (parue fin Novembre 2012) et le projet est encore considéré comme en beta. C’est-à-dire qu’il existe encore de nombreuses erreurs et que de nouvelles fonctionnalités verront probablement le jour.

Une petite anecdote est que J2ObjC fait appel au compilateur C installé sur votre machine. C’est généralement GCC mais aussi … LLVM.

LLVM, un projet ambitieux

LLVM est à la base un projet ambitieux de l’Université de l’Illinois, soutenue par Apple. LLVM signifie Low Level Virtual Machine (Machine virtuelle de bas niveau) ce projet permettant de construire des machines virtuelles. De telles machines virtuelles autorisent la compilation à la volée.

Certes LLVM n’est pas réellement un traducteur de code, il fournit plutôt une infrastructure de compilateur. Mais il nous intéresse car il permet de compiler de nombreux langages tout en optimisant le code généré. De plus il permet de traduire n’importe quel langage supporté par GCC ou Clang (Ada, C, C++, Fortran, Java, Objective-C, Objective-C++) en C, C++ ou CIL.

Rappelons les 3 parties qui composent la plupart des compilateurs :

  • Un front end, qui prend en entrée le code source, en fait l’analyse syntaxique et le transforme en un arbre syntaxique abstrait (AST : Abstract Syntax Tree).
  • Un optimiseur, qui effectue une multitude de transformations dans le but d’améliorer les performances du code machine qui sera généré.
  • Un back end, qui finalement génère le code machine.

Organisation d'un compilateur

A l’origine ce projet ne comportait que les 2 derniers composants d’un compilateur, c’est le cœur du projet. Mais au fur et à mesure, de nombreux sous projets sont arrivés et permettent également d’effectuer la première étape.

Une des forces de LLVM est la représentation intermédiaire du code, le LLVM IR (intermediate representation). Ceci est le code d’entrée de l’optimiseur. Il a été conçu dans de nombreux buts tels que l’optimisation de code ou la bonne définition de sa sémantique. Ce langage est fortement typé et peut être revu tel que ce fut le cas en décembre 2012 lors de la version 3.0 du projet.

Un des importants sous projet est Clang. Celui-ci est un véritable compilateur utilisant le cœur de LLVM. Il prend en charge de manière quasi-complète le C/C++/Objective C (d’où le nom Clang pour C langage). Il concurrence véritablement le célèbre compilateur GCC. On annonce qu’il possède une vitesse de compilation bien plus importante que GCC (environ 3 fois plus vite !).

De plus, un des reproches souvent effectué à GCC est le manque de clarté lors de d’erreurs de compilations. Or Clang fournit une meilleure analyse des erreurs commises pour la compilation, permettant de rectifier facilement des petites erreurs tel qu’une erreur de majuscule (si on écrit Int au lieu de int par exemple). De quoi faciliter la vie d’un développeur ou aussi apprendre plus facilement ces langages.

Ce sous projet est soutenu, cela peut paraître stratégique. Il pourrait permettre de remplacer l’ancien compilateur GCC et permettre à Apple d’avoir son propre compilateur concurrent. Pour cause à partir de la version 3.0, ce compilateur prend en charge de manière quasi complète ces 3 différents langages, ne supportant pas que certaines fonctionnalités exotiques de ces langages.

Un autre sous projet important est Dragon Egg. Ce dernier remplace l’optimiseur GCC et prend en charge de nombreux langages. Il a pour but de rendre LLVM apte à compiler de nombreux codes, une volonté de départ de ce projet est la compilation de tous langages. Ainsi avec Dragon Egg, on peut parfaitement compiler du C, C++, Ada et Fortran. On peut considérer aussi la compilation de programmes écrits de Obj-C, Obj-C++ et Go. Il supporte aussi un peu la compilation de code Java.

LLVM totalise 10 sous projets, accessibles depuis la page de garde du projet. Il est soutenu par d’importants organismes tels qu’Apple, son avenir est donc certain. D’autres entreprises très importantes s’appuient également sur cette technologie, tel que NVidia avec son compilateur CUDA. Sa volonté de se vouloir indépendant des langages le rend très intéressant pour vouloir créer des traducteurs.

Sources : Architecture de LLVM, LLVM et Clang, Manuel de référence de LLVM

Sébastien Malkowiak, Yohann Facon

[TRAD2012] Quelques outils de traduction automatique de code

Les outils de traduction de langages sont des outils très complexes et qui demandent d’énormes efforts de développement et dont on a généralement besoin qu’un nombre limité de fois. C’est pourquoi il n’existe pas un grand nombre de traducteurs.

Beaucoup de ces outils sont fait par des communautés composées de passionnés et de personnes intéressées par le projet. Ce sont souvent des projets open source qui se concentrent en priorité sur les fonctionnalités dont les développeurs de ces projets ont le plus besoin. Certains resteront donc à un stade partiel de développement, mais il est possible d’en trouver quelques uns qui sont à la fois complets et fonctionnels.

Nous présentons ici une liste non exhaustive des outils que nous avons sélectionnés.

ROSE

ROSE est un framework open source écrit en C++ permettant de traiter des programmes écrits en divers langages de programmation(C, C++, FORTRAN) . Son principal intérêt est d’analyser le code, mais il peut permettre également de traduire un code dans un autre langage ou même optimiser ce code. Il est évidemment capable de lire des fichiers sources mais peut également analyser des fichiers compilés. Dans ce dernier cas, la palette d’actions est néanmoins plus restreinte.

A partir du code source d’un programme, ROSE génère un AST(Abstract Syntax Tree), qui décrit le code analysé. Cela permet d’avoir une vue du code non liée au langage de programmation utilisée.

ROSE assure différents points clés de l’analyse syntaxique (liste non exhaustive) :

  • Il permet d’identifier les flux d’informations au sein d’un programme. Ainsi il peut savoir dans quels états peut se trouver le programme.
  • Pour la programmation objet, il permet de reconnaître l’héritage de classe, ce qui peut être ardu avec de l’héritage multiple en C++
  • Il gère la virtualisation en C++

Cette analyse du code source lui permet d’optimiser celui-ci. Cela peut être la diminution de redondance dans le code ou l’optimisation du code des différentes boucles.
Avec toutes ses fonctionnalités, ce framework peut être utilisé en tant que réel traducteur. Ce qui lui a d’ailleurs valu une des 100 récompenses décernés par R&D Magazine en 2009.

F2c

Cet outil open source traduit le FORTRAN 77 vers le langage C. Il a été développé à partir du compilateur f77 car ce dernier était programmé en C et utilisait un compilateur C pour les dernières étapes de la compilation de FORTRAN 77.

L’avantage de cet outil est qu’il a été utilisé pour plusieurs traductions de taille importante et qu’il a été corrigé au fur et à mesure. Alors même s’il n’a pas subit de grosse modification depuis plusieurs années et est encore maintenu.

Malheureusement il n’est pas capable de traduire les versions plus récentes de Fortran. De plus le code C ainsi créé, bien qu’il puisse être compilé par un compilateur C, est très difficilement lisible par un humain

Ruby2c/Ruby2cext

Ces deux projets open source visent à traduire du code ruby en C. Ils sont à l’abandon depuis plusieurs années et ne concernent que des parties de ruby, mais si cela vous suffit ou si vous cherchez à faire votre traducteur de ruby vers C, il est toujours bon de savoir qu’ils existent.

Vala

Vala est un langage de programmation, très proche du C#. Il possède son propre compilateur, permettant de le transformer en C pour finalement le compiler. Cela permet à l’aide d’arrangement dans un code C# d’avoir une application plus rapide, bénéficiant de la vitesse d’exécution des programmes C#. Cela constitue un intérêt majeur de ce langage : bénéficier des méthodes de programmations dites modernes en gardant une vitesse d’exécution importante.

Aussi ce langage Vala a été créé pour être proche de nombreux langages objets. Cela lui permet d’être utilisé plus facilement en tant que librairie par d’autres langages objets tels que Java, Python ou C++.

Pyjamas

Pyjamas, ou pyjs, fait un peu plus que traduire du code écrit en python en code javascript, il traduit une application Python et ses bibliothèques en une application Javascript avec des bibliothèques. La version 2.5 de python est presque entièrement supportée ainsi qu’une partie de la version 2.6. De plus plusieurs modules standards de Python sont partiellement supportés (la liste des modules est disponible ici).

C’est un outil open source assez complet qui est toujours en cours de développement. Ainsi si il vous manque quelque chose dont vous avez besoin et qui pourrait être utile à d’autres, demandez le gentiment et avec un peu de chance, cela sera intégré.

Sources : Tutoriel pour ROSE, Article Wikipedia de f2c

Sébastien Malkowiak, Yohann Facon

[TRAD2012] La traduction : un art difficile

Lors de notre premier article, nous avons vu que la traduction de langage permet de répondre à une problématique de portabilité de logiciels, mais il en existe en réalité plusieurs :

  • Assurer la portabilité d’un programme.
  • Augmenter les performances d’un programme.
  • Faciliter la maintenance et la modification d’un programme.

Mais il existe de nombreux types de traducteurs de langage qui sont plus ou moins couramment utilisés :

  • Compilateur, le plus connu. Il traduit un language de haut niveau en assembleur ou directement en code machine.
  • Décompilateur. Il fait l’inverse en traduisant du code machine en code source.
  • Programme assembleur. Il traduit de l’assembleur (le langage) en code machine.
  • Désassembleur. Il traduit du code machine en assembleur.
  • Interpréteur. Il traduit un langage de haut niveau en un langage intermédiaire qui pourra être exécuté.
  • Traducteur. C’est lui qui fait la traduction entre deux langages de haut niveau.

Écrire tous nos programmes en assembleur permettrait de gagner en performances, et encore pas toujours de façon significative. Mais cela se fait au détriment de la portabilité, et les langages de haut niveau restent beaucoup plus faciles à écrire, lire et maintenir.
C’est donc surtout cette dernière catégorie des Traducteurs qui nous intéresse, ainsi que quelques interpréteurs multiples.

Green code

Evidemment la mise en place de telles traduction n’est pas chose aisée. La première des étapes qui vient à l’esprit est la décomposition analytique (parsing en anglais). Cela permet de reconnaître différentes portions logiques de code afin d’être capable de les transposer en un différent langage. Cela peut être par exemple la transposition d’une boucle for en java vers une boucle for en C++.

Néanmoins, si cela semble l’étape principale, elle est en réalité loin d’être suffisante. Un premier obstacle elle est la nature même du langage. En effet, comment retranscrire un langage fonctionnel en langage objet? La méthodologie établie pour programmer sous ces différents langages est fondamentalement différente, et se pose donc en obstacle. Il semble difficile de créer automatiquement des classes de manière cohérente à partir de code ne comportant aucune de ces entités.

Autre problème, la dépendance d’un programme vers d’autres bibliothèques. Ces bibliothèques sont conçues pour certains langages et peuvent ne pas pouvoir être appelées par le langage cible de la traduction. On peut penser à traduire ces bibliothèques. Malheureusement, si l’open source prend une place de plus en plus importante dans le monde informatique, certaines bibliothèques ne fournissent qu’une API et ne permettent donc pas leur traduction.

Certains langages s’imbriquent les uns aux autres, l’exemple le plus célèbre est probablement le HTML avec du php et/ou du JavaScript. Ainsi l’outil de traduction doit analyser simultanément différentes natures de code sur un même fichier. Cela complexifie de nouveau l’agencement du code en sortie de traduction.

D’autres notions sont propres aux langages eux-mêmes, et ne possèdent simplement pas d’équivalent. On peut citer par exemple le garbage collector. Ainsi traduire un programme Java en C++ poserait de nombreux problèmes de gestion mémoire, où on devrait créer des destructeurs et gérer de manière habile l’appel à ceux-ci.

Sources : Life After Parsing, Translator (computing), Image

Sébastien Malkowiak, Yohann Facon

[TRAD2012] Comparaison des outils de traduction automatique de code

Ce projet a été proposé par Guillaume Moreau de l’Ecole Centrale de Nantes dans le cadre du projet de Veille Technologique des troisièmes années en option Informatique.

Code informatique et le TerreLe monde de l’informatique connaît un essor croissant du nombre de langages. Ceux-ci ont chacun leur particularité, leur mode de fonctionnement, leur intérêt. Ainsi selon l’application à développer, on préférera certains langages. Par exemple, dans le monde des jeux vidéos, le C++ est très souvent utilisé car il est très rapide.
A cela s’ajoute la multiplicité des OS, notamment avec l’arrivée des smartphones. En effet, ils utilisent chacun des langages différents : du java sous Androïd, de l’objective C sous iOS… Dans le contexte actuel où la plupart des fonctionnalités sont présentes sur toutes les plates-formes, avoir des applications plus riches ou mieux optimisées est un des seuls moyens de se démarquer.

Ainsi la traduction de langage permettrait de développer plus facilement des applications sur différentes plates-formes. Avec un outil de traduction de qualité, on peut même imaginer avoir une application développée sur une seule plate-forme et fonctionnant de la même façon, indépendamment de la machine sur laquelle elle est portée.

De telles méthodologies ont donc de réels intérêts économiques. La preuve en est avec le développement récent de J2ObjC par Google qui permet de traduire du code logique écrit en java vers l’objective C.

Pour vous tenir au courant des évolutions de ce type d’outils, tout au long de cette année nous allons :

  • Recenser différentes méthodologies existantes
  • Recenser différents outils existants
  • Définir des critères de qualité pour cette technologie
  • Tests d’efficacité des différents outils
  • Comparatif des outils suite à ces tests

Évidemment, une technologie aussi active que cela est largement susceptible d’évoluer lors des mois à venir, nous devrons donc également se préoccuper de l’évolution des différents outils du marché.

Sébastien Malkowiak
Yohann Facon

Licence de l’image : CC0 1.0