Brevet FR2932905A1 — publié le 20091225

MOBILEDISTILLERYI .FRD Dispositif de configuration adaptative L'invention concerne un dispositif de configuration adaptative informatique. De nos jours, le nombre de dispositifs électroniques personnels disponibles a explosé. Devant la diversité des systèmes d'exploitation existant, et avec la réduction du temps de vie des produits, l'utilisation de machines virtuelles a explosé. Ainsi, un grand nombre de programmes pour téléphones mobiles sont maintenant codés en java, et plus particulièrement en J2ME. Cependant, malgré la standardisation que le java offre, de nombreux paramètres propres aux téléphones rendent encore nécessaire la production de codes sources personnalisés pour chaque téléphone. Pour contourner cet obstacle, des logiciels ont été développés qui fournissent des librairies et ou API java qui peuvent être utilisées pour écrire un programme quelque soit le téléphone, et qui produisent ensuite de tels codes adaptés à chaque téléphone. Un exemple d'un tel logiciel est le logiciel Celsius de Mobile Distillery. Dans ce cas, avant traitement par Celsius, le code est qualifié de "code de pré-programme". Cependant, même si ces logiciels permettent de simplifier la création du code en offrant une seule source générique, la gestion en aval de la multiplicité de codes binaires résultante est complexe. En outre, chaque code binaire nécessite une validation qui est obtenue par l'achat d'un certificat relativement cher. Produire un programme pour une pluralité de dispositifs mobiles est donc actuellement complexe et onéreux. L'invention vient améliorer la situation. A cet effet, l'invention propose un dispositif de configuration adaptative, comprenant une mémoire de stockage, avec des identifiants de code et des données de paramètres mettant en correspondance des identifiants de code et des identifiants de produit électronique, une mémoire de travail, propre à recevoir une ou plusieurs listes d'identifiants de produit électronique, un analyseur syntaxique, propre à parcourir du code de programme informatique 1 pour extraire une liste d'identifiants de code, un requêteur, agencé pour déterminer dans la mémoire de stockage des données de paramètres correspondant à un identifiant de produit électronique et un identifiant de code donnés, un comparateur, agencé pour définir une valeur de similarité entre des données de paramètres reçues en entrée, et un pilote, agencé pour : * appeler l'analyseur syntaxique avec des données de code de programme informatique reçues en entrée pour établir une liste d'identifiants de code de travail ; * pour chaque liste d'identifiants de produit électronique reçue dans la mémoire de travail, et pour certains au moins des identifiants de code la liste d'identifiants de code de travail : - appeler répétitivement le requêteur avec chaque identifiant dans la liste d'identifiants de produit électronique et avec l'identifiant de code courant, pour établir une liste de données de paramètres, en maintenant une correspondance avec la liste d'identifiants de produit électronique ; appeler répétitivement le comparateur avec les données de la liste de données de 15 paramètres, pour établir une liste de valeurs de similarité, en maintenant une correspondance avec la liste d'identifiants de produit électronique ; - déterminer une ou plusieurs nouvelles listes d'identifiants de produit électronique comprenant chacune des identifiants de produit électroniques dont les valeurs de similarité correspondantes vérifient un critère choisi, et 20 - remplacer dans la mémoire de travail la liste d'identifiants de produit électronique par la ou les nouvelles listes d'identifiants de produit électronique. Un tel dispositif est extrêmement avantageux car il permet de regrouper entre eux les dispositifs pour lesquels le code est proche sinon identique. Cela permet une gestion des 25 versions automatisée et simplifiée, et une grande réduction des coûts de validation. L'invention concerne également un procédé de configuration adaptative qui comprend : a. recevoir une ou plusieurs listes d'identifiants de produit électronique, avec des données de code de pré-programme informatique ; 30 b. appeler un analyseur syntaxique avec lesdites données de code de pré-programme informatique, pour établir une liste d'identifiants de code de travail ; c. définir un identifiant de code de travail courant ; d. définir une liste d'identifiants de produit électronique courante ; e. tirer d'une mémoire de stockage une liste de données de paramètres, en correspondance avec la liste d'identifiants de produit électronique courante et l'identifiant de code courant ; f. comparer répétitivement les données de la liste de données de paramètres, pour déterminer une ou plusieurs nouvelles listes d'identifiants de produit électronique dont les données de paramètres vérifient un critère choisi ; g. remplacer la liste d'identifiants de produit électronique courante par la ou les nouvelles listes d'identifiants de produit électronique ; h. répéter les étapes d. à g. jusqu'à ce que toutes les listes d'identifiants de produit électronique aient été traitées ; i. répéter les étapes c. à h. jusqu'à ce que tous les identifiants de code de travail aient été traités. D'autres caractéristiques et avantages de l'invention apparaîtront mieux à la lecture de la 15 description qui suit, tirée d'exemples donnés à titre illustratif et non limitatif, tirés des dessins sur lesquels : la figure 1 représente une vue schématique d'un dispositif selon l'invention ; la figure 2 représente un diagramme schématique d'une opération réalisée par le dispositif de la figure 1 ; 20 - la figure 3 représente un exemple d'implémentation d'une opération de la figure 2 ; la figure 4 représente un exemple d'implémentation d'une autre opération de la figure 2 ; les figures 5 et 6 représente des exemples d'agencement de données traitées dans les opérations des figures 2 à 4 ; 25 - la figure 7 représente une opération optionnelle de l'opération de la figure 4 ; la figure 8 représente un exemple d'agencement de données résultant de l'opération de la figure 7 ; et - la figure 9 représente une variante de la figure 1. 30 Les dessins et la description ci-après contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la présente invention, mais aussi contribuer à sa définition, le cas échéant. La présente description est de nature à faire intervenir des éléments susceptibles de protection par le droit d'auteur et/ou le copyright. Le titulaire des droits n'a pas d'objection à la reproduction à l'identique par quiconque du présent document de brevet ou de sa description, telle qu'elle apparaît dans les dossiers officiels. Pour le reste, il réserve intégralement ses 5 droits. La figure 1 représente une vue schématique d'un dispositif selon l'invention. Le dispositif 2 comporte une mémoire de stockage 4, une mémoire de travail 6, un analyseur syntaxique 8, un requêteur 10, un comparateur 12 et un pilote 14. La mémoire de stockage 4 reçoit un dictionnaire de librairie 16 et une base de connaissance 18. La mémoire de travail 6 reçoit un fichier 20 contenant du code de programme informatique, qui est dans l'exemple décrit ici du code java. 15 Le fichier 20 contient du code de pré-programme qui est destiné à être interprété en fonction du téléphone sur lequel on cherche à porter le code du fichier 20. Ce code destiné à être interprété est détecté au moyen de mots-clés qui peuvent être des noms de méthode, des noms de variables, ou des instructions spécifiques. 20 L'invention n'est donc pas limitée au code en java, et elle peut être étendue à tout type de code de programme informatique que l'homme du métier saura utiliser. Avec le fichier 20, le pilote 14 appelle l'analyseur syntaxique 8, qui utilise le dictionnaire 16 pour retourner un fichier 22 comprenant une liste de méthodes ou d'autres mots-clés identifiés dans le code du fichier 20. 25 La mémoire de travail 6 reçoit également un fichier 24 comprenant une liste de téléphones que l'on souhaite classer. Avec le fichier 22 et le fichier 24, le pilote appelle le requêteur 10 et le comparateur 12, qui interagissent avec la base de connaissance 18 pour établir un fichier 26. Le fichier 26 contient une pluralité de listes de téléphones semblables à celle du fichier 24 qui ont été rassemblés par correspondance dans le dispositif 2, sur la base des mots-clés identifiés dans le fichier 20. 10 30 Dans l'exemple décrit ici, les dispositifs de destination de portage sont des téléphones mobiles qui mettent en oeuvre une machine virtuelle java au moyen de J2ME. Cependant, l'invention s'applique à tout ensemble de produits électroniques sur lesquels on cherche à réaliser un portage d'un code générique. Par ailleurs, les mémoires 4 et 6 peuvent être réalisées de toute manière connue de l'homme du métier, par exemple sous la forme de disques durs, de mémoires optiques de type CD ou DVD ou autre, et ne sont pas nécessairement rassemblées physiquement avec les autres éléments du dispositif 2. Ainsi, ces mémoires peuvent être accédées par réseau, ou par tout autre moyen que l'homme du métier connaît. Ainsi, grâce au dispositif 2, en partant d'un code de pré-programme générique que l'on cherche à porter sur des téléphones, et d'une liste de tels téléphones, on peut établir une pluralité de listes de téléphones. Pour chaque liste, un portage peut être réalisé, ce portage étant identique pour tous les téléphones d'une même liste. La manière avec laquelle le dispositif 2 établit ces listes va maintenant être décrite avec les figures 2 à 9. La figure 2 représente un diagramme schématique des opérations du dispositif 2 sur les fichiers 20, 22 et 24. Dans une opération 200, le dispositif 2 reçoit dans la mémoire 6 les fichiers 20 et 24. Comme on l'a vu plus haut, ce sont ces fichiers qui vont servir de base au regroupement des téléphones. Dans une opération 300, le pilote 14 appelle une fonction Anl() qui sera détaillée avec la figure 3. La fonction Anl() reçoit comme argument le code java du fichier 20, et appelle l'analyseur syntaxique pour en extraire des mots-clés contenus dans le dictionnaire 16 comme vu plus haut. Le résultat est stocké dans le fichier 22. Ensuite, dans une opération 400, le pilote 14 appelle une fonction Comp() qui sera détaillée avec la figure 4. La fonction Comp() reçoit comme argument le fichier de mots-clés 22 et le fichier 24 de la liste de téléphones, et appelle le requêteur 10 et le comparateur 12 en accédant à la base de connaissance 18 pour regrouper les téléphones par groupe.30 Dans chaque groupe, les téléphones sont identifiés comme similaires ou identiques pour le portage d'un code associé aux mots-clés du fichier 22. L'ensemble de ces groupes est renvoyé et stocké dans le fichier 26. L'opération 300 va maintenant être décrite en référence à la figure 3. L'opération part en 302 de la réception des arguments de la fonction An1O, à savoir le code contenu dans le fichier 20. Une boucle est alors lancée en 304, dans laquelle une chaîne de caractères Str est extraite du code. Dans une opération 306, la chaîne Str est recherchée dans le dictionnaire 16 au moyen d'une fonction Dic(). Lorsque la chaîne Str est présente dans le dictionnaire 16, cette chaîne est rajoutée en 308 à la variable Meth_Lst qui sera retournée en résultat. Ensuite, ou lorsque la chaîne Str n'est pas présente dans le dictionnaire 16, la boucle se termine par un test 310 sur le texte restant dans le fichier 20. Si le fichier 20 est non vide, alors la boucle reprend en 304. Sinon, l'opération 300 se termine en 312 avec le renvoi de la variable Meth Lst dans le fichier 22. Dans l'exemple décrit ici, les mots-clés recherchés sont des noms de méthodes liées à la librairie Celsius. Cette librairie permet de produire un code de pré-programme en java qui est adapté pour tous 25 les téléphones mobiles du marché. Pour cela, le programmeur fait appel, pour les éléments dont la mise en oeuvre est spécifique aux téléphones, à des méthodes génériques. Ensuite, ce code java "agnostique" peut être traité par le logiciel CELSIUS, pour mettre en oeuvre les méthodes de la librairie de manière spécifique à chaque téléphone. Dans d'autres modes de réalisation, le dictionnaire peut contenir d'autres éléments, comme des noms de variable ou autres. 30 L'opération 400 va maintenant être décrite en référence à la figure 4. L'opération part en 402 de la réception des arguments de la fonction Comp(), à savoir le fichier 22 avec la liste de mots-clés Meth_Lst, et le fichier 24 qui comprend une liste des téléphones que l'on souhaite regrouper pour réaliser un portage unique. Ensuite, cette liste d'identifiants de téléphones est stockée dans un tableau Tel_Lst Arr dans une opération 403. Ensuite, une double boucle commence en 404 avec le dépilage d'un mot-clé courant Par du fichier 22. La double boucle fonctionne ainsi : - la première boucle est un dépilage des mots-clés du fichier 22 ; - la deuxième boucle est un dépilage des listes de téléphones du tableau Tel_Lst_Arr. La deuxième boucle permet de regrouper entre eux les téléphones pour lesquels la base de connaissance indique qu'ils ont un portage similaire pour le mot-clé courant. Dans une opération 406, le mot-clé courant est recherché dans la base de connaissance 18 pour déterminer s'il correspond à un portage discriminant. Par portage discriminant on entend le fait que deux téléphones qui ont une mise en oeuvre différente du code associé au mot-clé courant nécessitent deux portages distincts. Par exemple, si le mot-clé porte sur le type de fichiers son utilisés, il sera nécessaire de prévoir un portage pour les téléphones compatibles MIDI uniquement, et un autre pour les téléphones compatibles MP3. Dès lors, le mot-clé associé est considéré comme discriminant. Si le mot-clé courant ne correspond pas à un portage discriminant, alors la deuxième boucle est évitée, et l'opération peut être prolongée par une opération de dynamisation 408 optionnelle décrite avec la figure 7. Ensuite, la première boucle se termine avec une opération 410 dans laquelle on vérifie s'il reste d'autres mots-clés à analyser. S'il est déterminé que le mot-clé courant correspond à un portage discriminant, alors la 30 deuxième boucle est lancée avec la récupération en 412 d'une liste de téléphones Tel_Lst_Tmp à partir du tableau Tel_Lst_Arr. Comme on l'a vu plus haut, le tableau Tel_Lst Arr est initialisé avec la liste Tel_Lst du fichier 24. Ainsi, lors de la première itération, le tableau Tel_Lst_Arr contient une seule liste de téléphones, qui contient tous les téléphones que l'on cherche à regrouper. Peu à peu, comme cela apparaîtra, le nombre de listes dans le tableau Tel_Lst_Arr augmente, au fur et à mesure que l'on détecte différents portages nécessaires. Une fois la liste de téléphones courante Tel_Lst_Tmp récupérée, un tableau Spl est mis à zéro en 414. Le tableau Spl est ensuite rempli pour chaque téléphone de la liste Tel_Lst_Tmp avec une valeur indicative du portage associé au mot-clé courant Par sur chacun de ces téléphones. Pour cela, une boucle est lancée en 416 dans laquelle la liste Tel_Lst_Tmp est dépilée pour 10 obtenir un identifiant de téléphone Tel. Cette opération est suivie en 418 de l'appel du requêteur avec l'identifiant Tel et le mot-clé courant Par (ou un identifiant de ce mot-clé) avec une fonction Val(). 15 La fonction Val() appelle la base de connaissance 18 avec ces deux paramètres et stocke la valeur correspondante dans le tableau Spi. Ensuite, un test vérifie en 420 si la liste Tel_Lst_Tmp a été entièrement parcourue, et par conséquent si l'ensemble des valeurs indicatives de portage ont été récupérées ou non. S'il 20 reste des téléphones, les opérations 416 et 418 sont répétées. Sinon, une fonction Split() est appelée en 422. La fonction Split() prend le tableau Spl en argument, et retourne un fichier comprenant une ou plusieurs listes de téléphones New_Lst. La fonction Split() a pour rôle d'analyser les valeurs indicatives de portage du tableau Spi, et de retourner sous forme d'une ou plusieurs listes dans la liste New Lst les identifiants des téléphones, rassemblés par portage identique. 30 La fonction Split() peut être mise en oeuvre de plusieurs manières. Dans le mode de réalisation décrit ici, la fonction Split() appelle le comparateur 12 avec chaque paire de valeurs du tableau Spi. Le comparateur 12 renvoie à chaque fois une valeur qui indique si la paire de valeurs est identique ou suffisamment similaire pour réaliser un 25 portage identique, et la fonction Split() classe les identifiants de téléphone en listes séparées selon la valeur de similarité. L'homme du métier saura envisager d'autres modes de réalisation de la fonction Split(). On notera qu'en résultat de la fonction Split(), New_Lst comprend les mêmes identifiants de téléphone que Tel_Lst_Tmp. Cependant, dans New Lst, ces identifiants sont agencés en listes qui ne se recoupent pas. L'opération 422 est une segmentation de la liste de téléphones Tel_Lst_Tmp en une ou plusieurs listes selon la nécessité de portage particulier. Ainsi, dans le cas où un seul portage convient pour les téléphones de la liste Tel_Lst_Tmp pour le paramètre Par, la liste New_Lst est identique à la liste Tel_Lst_Tmp. Ensuite, en 422, le fichier New_Lst est ajouté dans un fichier New Tel_Lst Arr. Le tableau 15 Tel_Lst_Arr, la liste New Lst, et la liste New_Tel_Lst peuvent être vus comme représentés sur la figure 5, c'est-à-dire comme un tableau de listes de téléphones. Chaque liste de téléphones de ces éléments, tout comme la liste Tel_Lst du fichier 24, peut être vue comme représenté sur la figure 6, c'est-à-dire comme un tableau d'identifiants de 20 téléphones. La deuxième boucle se prolonge en 426 avec le test de la liste Tel_Lst_Arr. Si cette liste est vide, cela signifie que toutes les listes de Tel_Lst_Arr ont été parcourues pour le mot-clé courant Par, et séparées et rangées comme nécessaire dans la liste New Tel Lst Arr. La deuxième boucle est alors terminée en 428 avec le remplacement de la liste Tel_Lst_Arr par la liste New Tel_Lst Arr. Le test de l'opération 410 détermine alors si tous les mots-clés ont été parcourus. 30 Si c'est le cas, la fonction Comp( se termine en 430 avec le renvoi du fichier 26 qui contient la liste Tel_Lst_Arr. Sinon, la liste Tel_Lst_Arr mise à jour est encore analysée avec le mot-clé suivant avec l'opération 404. 25 Ainsi, en partant d'une liste de téléphones globale, on parcourt progressivement chacun des mots-clés et on segmente la liste successivement à chaque fois qu'un élément indiquant la nécessité d'un portage distinct est détecté. A la fin, on obtient une pluralité de listes de téléphones pour lesquels on sait que le même portage peut être réalisé par rapport aux mots-clés trouvés dans le fichier 20. La figure 7 représente une mise en oeuvre exemplaire de l'opération optionnelle 408. Cette opération vise à établir une table de dynamisation Dyn_Lst qui permet de réduire le nombre de listes de téléphones en réduisant la criticité des valeurs indicatives de portage. Par exemple, il se peut qu'un mot-clé soit associé à une largeur d'écran, ou à une correction d'erreur spécifique à un téléphone. En principe, ce type de différences devrait être considérée comme critique, et impliquer la génération de portages distincts, c'est-à-dire la segmentation des listes de téléphones. Cependant, comme il s'agit de modifications légères, comme une valeur à changer ou un court morceau de code à rajouter conditionnellement, il peut être intéressant de les classer comme portage non discriminant, et de prévoir la génération d'informations permettant de gérer les différents cas dans l'opération 408. De fait, l'opération 408 est très proche dans sa mise en oeuvre de la deuxième boucle de la figure 4, et les opérations 702, 706, 708, 710, 712 et 716 sont identiques aux opérations 412 à 420 et 426. Les opérations 704 et 718 ont pour rôle la conservation de la liste Tel_Lst_Arr courante (on rappelle que l'opération 408 ne modifie pas cette liste, mais se contente d'établir des paramètres de dynamisation). Après l'opération 718, l'opération 408 se termine en 720. 30 L'opération 714 est l'appel d'une fonction Dyn() qui prend comme argument le tableau Spl et ajoute à la table Dyn_Lst les différentes valeurs indicatives de portage qu'il contient en correspondance à chaque fois du téléphone d'identifiant Tel et du mot-clé courant Par correspondants.25 La figure 8 montre un exemple de la table Dyn_Lst. Ainsi, une fois que tous les mots-clés ont été testés et que les téléphones ont été répartis en listes de portage, le logiciel Celsius peut utiliser ces listes ainsi que la table Dyn_Lst pour générer les portages adaptés tenant compte de toutes les spécificités de chaque téléphone. On notera que les valeurs de la table Dyn_Lst peuvent être relatives ou absolues. Ainsi, certains paramètres comme la taille de police peuvent être réglés à des valeurs par défaut, et il convient alors de stocker la différence entre cette valeur et celle de chaque téléphone. Inversement, certains paramètres comme les formats d'image compatibles, ou la meilleure police affichable sont de nature absolue et doivent être stockées individuellement. La figure 9 représente une variante de la figure 2. Dans cette figure, l'étape optionnelle 408 est mise en oeuvre. Ainsi, elle comporte les trois opérations 200, 300 et 400 décrites précédemment. Ces opérations sont complétées par une opération 900 et une opération 920. L'opération 900 a pour fonction la génération d'un algorithme de détermination de téléphone. En effet, les versions actuelles de J2ME ne permettent pas de déterminer le téléphone sur lequel une machine virtuelle java fonctionne. Dès lors, pour permettre d'utiliser les données de la table Dyn_Lst, il faut établir un 20 algorithme, qui permet à chaque téléphone de déterminer les paramètres dynamiques qui lui correspondent. Cela est réalisé par une fonction Diff(), qui génère un fichier Tel_Alg_Arr. Le fichier Tel_Alg_Arr va contenir un ou plusieurs algorithmes qui permettent aux téléphones 25 d'identifier les données dynamiques qui leur correspondent, et une ou plusieurs bases de données qui contiennent ces données dynamiques. Au gré des segmentations de Tel_Lst Arr, chaque liste particulière va voir son nombre de téléphones diminuer. Ainsi, lors du portage du code du fichier 22 pour cette liste particulière, 30 les données de Dyn_Lst sont pour la plupart non reliées aux téléphones particuliers de cette liste. La fonction Diff() peut donc être mise en oeuvre de nombreuses manières différentes, selon que l'on tiendra compte de cette excès de données ou pas. Dans une première mise en oeuvre, il n'est pas tenu compte du fait que la plupart des informations contenues dans Dyn_Lst ne sont réellement utiles que pour un nombre limité de téléphones. La liste Dyn_Lst est ainsi incorporée entièrement dans Tel_Alg_Arr, et intégrée dans chaque portage. Pour permettre aux téléphones d'accéder aux données de Dyn_Lst qui les concerne, il est alors utile de prévoir un algorithme ou une formule qui renvoie un indice de chaque téléphone en fonction de ses particularités, cet indice correspondant à un index correspondant dans Dyn_Lst. Cette première mise en oeuvre est gourmande en ressources, car on va stocker des données inutiles dans chaque portage, ainsi qu'une formule relativement complexe (car adaptée à la détection de n'importe quel téléphone). Elle présente l'avantage d'offrir une approche unifiée qui ne se préoccupe pas vraiment des listes de téléphones établies aux étapes précédentes. Dans une deuxième mise en oeuvre, il est tenu compte du fait que la plupart des informations contenues dans Dyn_Lst ne sont réellement utiles que pour un nombre limité de téléphones. La liste Dyn_Lst est donc segmentée en une pluralité de sous-listes qui sont particulières à chaque liste de téléphones de Tel_Lst_Arr. 20 Pour permettre aux téléphones d'accéder aux données de la sous-liste qui les concerne, il est alors utile de prévoir un algorithme ou une formule qui renvoie un indice de chaque téléphone en fonction de ses particularités, cet indice correspondant à un index correspondant dans la sous-liste. Une telle formule peut être fortement simplifiée en se basant sur les différences des 25 téléphones entre eux au sein de la sous-liste. Cette deuxième mise en oeuvre est économe en ressources, car on va stocker uniquement les données utiles à chaque portage, et la formule d'identification peut être simplifiée (car adaptée à la détection d'un téléphone au sein d'une sous-liste restreinte). Elle présente l'avantage 30 d'offrir une approche personnalisée pour chaque liste de téléphones établie aux étapes précédentes. Enfin, l'opération 920 est réalisée par une fonction Compile(), qui utilise les fichiers 20 et 26 pour produire une pluralité de fichiers JAR et JAD qui correspondent au portage du code du 10 15 fichier 20 sur chaque liste de téléphone. Pour cela, cette fonction appelle le logiciel Celsius, ce qui permet en outre de produire un code offusqué. Grâce au dispositif décrit ci-dessus, il est possible de réduire grandement le nombre d'exécutables différents pour le portage d'une application donnée. Cela présente un nombre conséquent d'avantages, comme la gestion simplifiée des versions, la réduction du nombre de certificats de validation à payer pour certifier la compatibilité du programme, etc. Ce qui précède a été présenté avec référence particulière aux téléphones mobiles, et au portage d'applications java sur ces téléphones. Il va de soi que l'invention ne se limite ni à ces dispositifs, ni à ce type de langage, et englobe tous les cas où un portage d'un code générique est nécessaire sur un nombre conséquent de dispositifs électroniques. En outre, il conviendra d'apprécier que les variantes décrites plus haut peuvent être combinées 15 entre elles autant que faire ce peu. La liste exhaustive de ces combinaisons n'a pas été listée ici par souci de clarté, et non parce qu'elles n'étaient pas envisagées. Enfin, de nombreuses modifications apparaîtront à l'homme du métier, comme : - la possibilité de classer directement la liste de mots-clés par criticité de portage dans 20 l'analyseur syntaxique, - la possibilité de classer la liste de mots-clés par criticité de portage avant de commencer à établir le tableau Tel_Lst_Arr, - la possibilité de limiter le nombre de listes de téléphones, ce qui force alors à dynamiser le code, 25 - etc. L'homme du métier envisagera bien sûr d'autres modifications similaires dans leur portée, qui restent dans l'esprit de l'invention. 30 Le dispositif peut prévoir que le code de pré-programme est compilé en une pluralité de codes de programme, à partir de la pluralité de listes d'identifiants de produit électronique établie, et des données de paramètres de code correspondantes. Le dispositif peut également prévoir que, pour chacun des identifiants d'une liste donnée, un seul code de programme est compilé. Revendications1. Dispositif de configuration adaptative, comprenant : une mémoire de stockage (4), avec des identifiants de code et des données de paramètres mettant en correspondance des identifiants de code et des identifiants de produit électronique, une mémoire de travail (6), propre à recevoir une ou plusieurs listes d'identifiants de produit électronique, un analyseur syntaxique (8), propre à parcourir du code de pré-programme informatique pour extraire une liste d'identifiants de code, un requêteur (10), agencé pour déterminer dans la mémoire de stockage des données de paramètres correspondant à un identifiant de produit électronique et un identifiant de code donnés, un comparateur (12), agencé pour définir une valeur de similarité entre des données de paramètres reçues en entrée, un pilote (14), agencé pour : * appeler l'analyseur syntaxique (8) avec des données de code de pré-programme informatique reçues en entrée pour établir une liste d'identifiants de code de travail ; * pour chaque liste d'identifiants de produit électronique reçue dans la mémoire de travail (6), et pour certains au moins des identifiants de code de la liste d'identifiants de code de travail : appeler répétitivement le requêteur (10) avec chaque identifiant dans la liste d'identifiants de produit électronique et avec l'identifiant de code courant, pour établir une liste de données de paramètres, en maintenant une correspondance avec la liste d'identifiants de produit électronique ; - appeler répétitivement le comparateur (12) avec les données de la liste de données de paramètres, pour déterminer une ou plusieurs nouvelles listes d'identifiants de produit électronique qui ont des valeurs de similarité entre eux qui vérifient un critère choisi, et remplacer dans la mémoire de travail (6) la liste d'identifiants de produit électronique par la ou les nouvelles listes d'identifiants de produit électronique. 2. Dispositif selon la revendication 1, caractérisé en ce que le requêteur (10) et le comparateur (12) sont appelés répétitivement pour des identifiants de code de la liste d'identifiants de code de travail pour lesquels un critère de criticité est établi. 14 3. Dispositif selon la revendication 1 ou 2, caractérisé en ce que, pour des identifiants de code de la liste d'identifiants de code de travail pour lesquels un critère de criticité n'est pas établi, le pilote (14) est en outre agencé pour appeler répétitivement le requêteur (10) avec chaque identifiant dans la liste d'identifiants de produit électronique et avec l'identifiant de code courant, pour stocker une liste de données de paramètres, en maintenant une correspondance avec la liste d'identifiants de produit électronique. 4. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le code de pré-programme est compilé en une pluralité de codes de programme, à partir de la pluralité de listes d'identifiants de produit électronique établie, et des données de paramètres de code correspondantes. 5. Dispositif selon la revendication 4, caractérisé en ce que, pour chacun des identifiants d'une liste donnée, un seul code de programme est compilé. 6. Dispositif selon l'une des revendications précédentes, caractérisé en ce que le code de pré-programme est du code java. 7. Procédé de configuration adaptative, comprenant : 20 a. recevoir une ou plusieurs listes d'identifiants de produit électronique, avec des données de code de pré-programme informatique ; b. appeler un analyseur syntaxique avec lesdites données de code de pré-programme informatique, pour établir une liste d'identifiants de code de travail ; c. définir un identifiant de code de travail courant ; 25 d. définir une liste d'identifiants de produit électronique courante ; e. tirer d'une mémoire de stockage une liste de données de paramètres, en correspondance avec la liste d'identifiants de produit électronique courante et l'identifiant de code courant ; f. comparer répétitivement les données de la liste de données de paramètres, pour 30 déterminer une ou plusieurs nouvelles listes d'identifiants de produit électronique dont les données de paramètres vérifient un critère choisi ; g. remplacer la liste d'identifiants de produit électronique courante par la ou les nouvelles listes d'identifiants de produit électronique ; 1.5h. répéter les étapes d. à g. jusqu'à ce que toutes les listes d'identifiants de produit électronique aient été traitées ; i. répéter les étapes c. à h. jusqu'à ce que tous les identifiants de code de travail aient été traités. 8. Procédé selon la revendication 7, dans lequel l'étape c. comprend : cl. définir un identifiant de code de travail courant ; c2. déterminer une criticité associée à l'identifiant de code de travail courant ; c3. si la criticité déterminée à l'étape c2. ne respecte pas un critère de criticité choisi, répéter l'étape cl. 9. Procédé selon la revendication 7, dans lequel l'étape c. comprend : c 1. définir un identifiant de code de travail courant ; c2. déterminer une criticité associée à l'identifiant de code de travail courant ; fl. si la criticité déterminée à l'étape c2. ne respecte pas un critère de criticité choisi, stocker ladite liste de données de paramètres en correspondance avec la liste d'identifiants de produit électronique courante et l'identifiant de code courant ; f2. sinon, comparer répétitivement les données de la liste de données de paramètres, pour déterminer une ou plusieurs nouvelles listes d'identifiants de produit électronique dont les données de paramètres vérifient un critère choisi.