Brevet FR3061578A1 — publié le 20180706

La présente invention relève du domaine des procédés de conception assistée par ordinateur. Elle concerne plus particulièrement un procédé de génération d'application logicielle permettant de manipuler des données variables liées entre elles, de façon conforme à des règles de cohérence, dans le but de créer un cahier des charges de fabrication d'un produit. Elle vise encore plus particulièrement un procédé de génération d'un configurateur apte à être mis en oeuvre par un opérateur ne possédant pas d'expertise dans le domaine du développement en informatique. Art antérieur Dans de nombreuses entreprises il est très utile, voire indispensable de recourir à un ou plusieurs logiciels dit « logiciels métier » qui sont organisés autour de la prise en compte d'un ensemble de contraintes techniques particulières auquel est soumise l'entreprise dans la réalisation de ses produits. Ces contraintes peuvent être liées au corps de métier auquel appartient l'entreprise ou à ses conditions spécifiques de produit, d'offre ou de fonctionnement. Il en résulte le besoin d'un logiciel, ou ensemble de logiciel, hautement personnalisé. Le développement de tels logiciels donne habituellement lieu à un cahier des charges spécifique. Ces logiciels sont habituellement développés par des opérateurs possédant une expertise dans le domaine du développement informatique. Du fait de l'intervention d'un expert informatique, ce développement s'avère couteux. Il n'est par ailleurs pas possible de modifier aisément des éléments au logiciel obtenu, d'en pré-visualiser l'utilisation en conditions opérationnelle ni de modifier des éléments du cahier des charges sans engager des coûts de développement supplémentaires important et/ou des délais important. Les systèmes de configurateurs de produits (appelés configurateurs) sont des technologies émergentes fondamentales souhaitées et sollicitées dans de nombreux métiers répondants à la demande instantanée des outils 3061578 2 internet de consommation de masse de produits configurables. Ces configurateurs sont installés sur le WEB comme interface entre les fabricants, les fournisseurs et leurs clients respectifs (en mode B2B et B2C). Le but est de proposer aux entreprises qui vendent des produits sur-5 mesure des solutions de configuration et des applications métiers de configurateurs. Les principaux enjeux du secteur portent sur le développement de produits « sur-mesure ». Des processus et des outils harmonisés et les plus génériques possibles pouvant répondre à la plus grande variété de besoins 10 possibles. Les temps de développement sont ainsi diminués et les compétences d'innovation sont mises en oeuvre pour aller plus loin, développer de nouvelles fonctionnalités ou accroître les performances des systèmes. Le marché des configurateurs est en profonde mutation par l'émergence d'acteurs majeurs dans le domaine des applications CPQ. Le travail se 15 fragmente selon des modes d'organisation nouveaux (besoin de disponibilité, mobilité, accessibilité des bases de données configuration produit via internet, multiplicité de configurateurs adaptés aux différents métiers des fabricants et fournisseurs). La pédagogie et la simplicité d'utilisation d'un configurateur sont la clef de voute de toutes les solutions B2B. 20 Cependant, une analyse des applications de gestion de configurateurs existants dans le monde montre qu'ils ne proposent pas une génération automatisée des produits qu'ils modélisent. Tous sont générés comme des outils spécifiques à la demande et figés qui intègrent un simple affichage d'écran et d'images figées sans pour autant permettre un indispensable 25 équilibre entre le besoin d'avoir des représentations de configuration évolutives en temps réel. On connait dans ce domaine notamment la demande de brevet français FR 2 999 314 Al du même demandeur, relative à un « procédé de création de simulateur de configuration client », dont la présente demande constitue un 30 perfectionnement. Cette précédente demande est relative à un procédé de création d'un générateur d'un ensemble de données dites "données de fabrication" d'un produit pouvant être configuré selon différentes variantes selon des paramètres 3061578 3 définissant les besoins et contraintes d'un client, lesdits paramètres pouvant varier de façon continue, ledit procédé étant destiné à être mis en oeuvre par un ordinateur comportant des moyens de communication à un réseau d'échange de données de type Internet, ladite application comportant une 5 interface homme-machine de type MVC, comportant un modèle de données, une interface visuelle et un contrôleur de logique des évènements. Le procédé comporte des moyens graphiques de définition de liens logiques entre les données, pour permettre à un utilisateur de développer ledit générateur de données de fabrication. Le contrôleur logique des évènements impose des 10 relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrables de règles dites "règles métier", définies par des seconds moyens graphiques de définition de liens logiques entre les données. La présente invention vise à rendre la création d'un tel générateur de données de fabrication encore plus simple, interactive et accessible à une 15 personne non spécialisée en développement informatique. Exposé de l'invention L'invention vise en premier lieu un procédé de création d'un simulateur logiciel d'un produit pouvant être configuré selon différentes variantes selon 20 des données définissant les besoins et contraintes d'un utilisateur client, ledit procédé étant destiné à être mis en oeuvre par un ordinateur comportant des moyens de communication à un réseau d'échange de données de type Internet, ledit simulateur logiciel comportant une interface homme-machine, comportant : un modèle de données, une interface visuelle, un contrôleur de 25 logique des évènements, ledit procédé comportant des premiers moyens graphiques de définition de liens logiques entre les données, pour permettre à un développeur d'une entreprise de développer ledit simulateur logiciel sans écrire directement de code informatique, le contrôleur logique des évènements imposant des relations entre les données du modèle et les éléments de la 30 visualisation selon un ensemble paramétrables de règles dites "règles métier", définies par des seconds moyens graphiques de définition de liens logiques entre les données. 3061578 4 Le procédé comporte une étape de génération de l'interface homme-machine dans laquelle un système informatique pose une série de questions au développeur de l'entreprise de manière à déterminer une logique du comportement d'un client lors du choix et de la définition d'un produit au cours 5 de l'utilisation du simulateur logiciel, puis, sur la base de règles de développement d'application web préalablement entrées en mémoire et formant des règles métier du développement d'une application web, le développeur de l'entreprise configure des briques logicielles proposées par le système en tenant compte de la logique du comportement déterminée, en 10 adaptant ces briques logicielles à l'entreprise, de manière à générer un simulateur logiciel par assemblage de ces briques logicielles. Dans un mode de réalisation particulier, les questions forment une arborescence et leur choix et enchainement est réalisé par le système de manière dynamique en fonction des réponses apportées aux questions 15 précédentes. Avantageusement, le module de définition de règles métier comporte des règles de cohérence applicables à ces règles métier, de manière à mettre en évidence les conflits éventuels entre certaines de ces règles lors de leur génération par le développeur de l'entreprise. 20 On comprend que l'invention est un procédé permettant de créer et adapter des applications intégrées sur mesure pour les supports PC, terminal nomade ou réseau web pour permettre à un utilisateur de concevoir, de développer et de déployer une application sur terminal informatique 25 (Tablette PC, Smartphone, PC), ladite application permettant, en temps réel ou en mode déconnecté, à des utilisateurs professionnels (par exemple des revendeurs de menuiserie, des concepteurs d'armoires électriques..), des utilisateurs commerciaux, du marketing ou du Bureau d'Études et Production, de configurer, gérer, éditer sur écran, imprimer et générer des données 30 structurées vers leurs bases de données (ERP, MRP, PDM) à partir d'informations des produits et services configurables obtenues en temps réel à travers des choix d'options et de variantes. 3061578 5 Dans la présente invention, la création de l'interface homme-machine fait elle-même l'objet de l'utilisation d'un configurateur, qui prend en compte des règles de génération d'application web, lesquelles constituent un ensemble particulier de règles métier. 5 L'invention vise sous un autre aspect un procédé de fabrication d'un produit pouvant être configuré selon différentes variantes selon des données définissant les besoins et contraintes d'un client, comportant un procédé de création d'un simulateur logiciel d'un produit tel qu'exposé plus haut. 10 Avantageusement, le procédé comporte une étape de génération d'un ensemble de données dite "données de fabrication", générées à partir des données d'affichage et d'un ensemble de règles de fabrication, préalablement défini. L'invention vise sous encore un autre aspect un produit / programme 15 d'ordinateur adapté à mettre en oeuvre un procédé tel qu'exposé plus haut. Présentation des figures Les caractéristiques et avantages de l'invention seront mieux appréciés grâce à la description qui suit, description qui expose les caractéristiques de 20 l'invention au travers d'un exemple non limitatif d'application. La description s'appuie sur les figures annexées qui représentent : Figure 1 : une vue schématique des éléments impliqués dans la mise en oeuvre d'un procédé conforme à la présente description, Figure 2 : un organigramme des différentes étapes du procédé, 25 Figure 3 : l'architecture du système expert d'aide à la génération d'application, Figure 4 : l'architecture du générateur d'application, Figure 5 : un organigramme des sous-étapes de l'étape 150 de création d'une interface IHM. 30 Description détaillée d'un mode de réalisation de l'invention Le procédé est destiné à être mis en oeuvre de façon logicielle par un ensemble de systèmes informatiques. 306 1 5 7 8 6 Le procédé comporte en premier lieu une phase 100 de création, par une entreprise 32, fabricant de produits ou de services, d'une application configurée selon un ensemble de règles de présentation d'information et de règles de calcul, ces règles étant spécifiques au métier de l'entreprise 32, et étant 5 usuellement désignées sous le nom de "règles métier" d'une entreprise (voir figures 1 et 2). Cette phase 100 de création est également appelée dans la suite de la description "configuration logicielle", le procédé étant alors cité sous le terme de "procédé de création de simulateur de configuration client". 10 On comprend qu'il s'agit d'une modélisation algorithmique des règles métier de l'entreprise 32, et de leur présentation sous une forme ergonomiquement astucieuse et ludique à un client 22 devant utiliser des données représentatives de variables liées au métier de l'entreprise 32. Le but est de parvenir à un système de simulation utilisable par un client 22, non 15 expert dans le métier de l'entreprise 32, et cependant conforme à toutes ses règles de cohérence. A titre d'exemple purement explicatif et nullement limitatif, l'entreprise 32 peut être un fabricant de portails. Ces portails sont réalisables selon diverses options, par exemple en un certain nombre de matériaux, formes et textures 20 différents, et selon diverses variantes, par exemple en largeur et hauteur variables. Dans un exemple plus détaillé, ils sont éventuellement divisibles en deux portes, dont la somme des largeurs correspond à une largeur d'emplacement d'implantation du portail. Différents matériaux peuvent être utilisés pour les portes, dans la mesure du respect de certaines contraintes 25 techniques. Les hauteurs des deux bords latéraux du portail peuvent varier, dans des limites de construction. On comprend que le but est ici de proposer un simulateur de configuration de portail, permettant à un client 22 de l'entreprise 32 de configurer un portail qui corresponde à ses données spécifiques et à ses 30 envies, sans jamais avoir à se préoccuper des règles métier qui régissent les relations des variables définissant le portail entre elles. Un tel configurateur doit permettre de faire varier de façon aussi continue que possible les paramètres 3061578 7 disponibles au client 22. Dans le même temps, une variable de coût de réalisation peut être associée en temps réel à chaque configuration. Un second but est de générer ensuite de façon correcte un cahier des charges de fabrication mis en forme selon les règles de présentation des 5 données pertinentes pour l'entreprise 32. Cette première phase 100 du procédé accepte donc en entrées des règles métier diverses et un mode de représentation graphique des données, et fournit en sortie un code source correspondant à un configurateur logiciel réalisant les buts spécifiés plus hauts, c'est-à-dire par exemple un logiciel de 10 définition d'une configuration de portail répondant aux besoins et contraintes particulières de clients 22. Dans cette phase 100 de création de configurateur logiciel, le procédé implique un premier système informatique 10, ici dit serveur de développement. Ce serveur de développement 10 comporte un écran d'affichage 11, et 15 héberge une ou plusieurs applications logicielles. Le serveur d'applications 10 est par exemple un ordinateur de type PC, connu en soi. Il dispose éventuellement de moyens classiques de communication au réseau, par voie filaire et/ ou radioélectrique. Il est adapté à héberger en mémoire et exécuter une application logicielle représentant la partie du procédé mise en oeuvre par 20 ledit serveur de développement 10. Le procédé comporte en second lieu une phase 200 d'utilisation de l'application logicielle créée, cette utilisation étant réalisée par exemple mais non limitativement dans les locaux de l'entreprise 32. Cette utilisation s'apparente, comme on l'a dit, à l'exécution d'un procédé de simulation. Ce 25 procédé de simulation permet par exemple de configurer un produit destiné à la fabrication selon les besoins spécifiques d'un client 22, et intégrant les règles métier de l'entreprise 32, c'est à dire, par exemple, des règles de fabrication et de dimensionnement. Le procédé implique en premier lieu, pour cette seconde phase 200, un 30 système informatique 15, ici dit serveur d'applications (voir figure 1). Ce serveur d'applications 15 comporte un écran d'affichage 11, et héberge une ou plusieurs applications logicielles. Le serveur d'applications 15 est par exemple un ordinateur de type PC, connu en soi. Il dispose de moyens classiques de 3061578 8 communication au réseau, par voie filaire et/ ou radioélectrique. Il est adapté à héberger en mémoire et exécuter une application logicielle représentant la partie du procédé mise en oeuvre par ledit serveur d'applications 15. Ce serveur d'applications 15 héberge notamment l'application logicielle 5 (dite configurateur) générée lors de la phase de configuration logicielle. La seconde phase 200 du procédé implique en outre au moins un second système informatique, dit ici terminal utilisateur 20. Dans le présent exemple, ce terminal utilisateur 20 est de type PC. Le terminal utilisateur 20 comporte des moyens de calcul (par exemple 10 microprocesseur), des dispositifs mémoire, et des moyens de communication 16 au réseau par voie radioélectrique. Il est adapté à télécharger et exécuter une application logicielle reprenant la partie du procédé mise en oeuvre par ledit terminal utilisateur 20. Un tel terminal utilisateur 20 est de type connu en soi, et n'est donc pas 15 détaillé plus avant ici. Dans un premier mode de réalisation, le terminal utilisateur 20 accède via un réseau de type Internet à un serveur d'application 15, sur lequel est exécutée l'application correspondant aux règles métier de l'entreprise 32. Dans un second mode de réalisation, le terminal utilisateur 20 et le 20 serveur d'application 15 sont confondus en une seule machine, sur laquelle est exécutée l'application logicielle (le simulateur de configuration). On comprend que cette seconde phase 200 du procédé peut impliquer plusieurs terminaux utilisateurs 20, ou de nombreux serveurs d'applications 15, dont les applications (simulateurs de configuration) sont éventuellement 25 totalement différentes et relatives à des produits indépendants de l'entreprise 32. Dans un mode particulier, le procédé met également en oeuvre un serveur de gestion de données d'entreprises ERP 30, associé à un ensemble de terminaux 35. Dans cette mise en oeuvre, les données modifiées par les 30 actions sur les terminaux utilisateurs 20 sur le serveur d'application 15 sont transférées vers le serveur ERP 30, par exemple sous forme de données de fabrication. 3061578 9 Étapes du procédé La figure 2 illustre un organigramme des étapes d'un procédé conforme à un mode de mise en oeuvre de l'invention tel que déjà décrit dans la demande de brevet FR 2 999 314 A1. L'étape 150, qui diffère dans la présente 5 invention, est décrite plus en détails à la fin de cette partie. Le procédé de création de configurateur est un modélisateur de structures hiérarchiques des données de l'entreprise 32. Le procédé de création de configurateur utilise en entrées une identification et une définition des variables à considérer dans l'application 10 client, un ensemble de règles de relations entre ces variables (inférences, équations entre ces variables...), des choix de modes de représentation de ces variables pour un client 22 non spécialiste. Ces entrées sont demandées progressivement à l'entreprise 32 lors de la création du simulateur de configuration, avec une capacité permanente à revenir sur des entrées 15 précédentes, et à modifier celles-ci, de façon interactive. On définit ci-dessous les principaux modules entrant dans la mise en oeuvre du procédé de configuration. Module de représentation et de manipulation des données 20 Structure hiérarchique de données Les données utilisées dans le procédé de configuration sont stockées et manipulées sous la forme d'un ou plusieurs structures hiérarchiques de données. La structure hiérarchique de données est la structure de base du moteur de configuration. Cette structure hiérarchique de données est celle qui 25 est utilisée dans le moteur d'inférence mis en oeuvre dans le procédé. La structure hiérarchique de données utilise des modules d'accès aux données et de liens entre les données pour son affectation et les ensembles de définitions de chaque valeur. La structure hiérarchique de données permet de stocker et de manipuler toutes les données de l'entreprise 32 avec une même logique 30 sans se soucier de sa persistance physique et de la manière dont cela est mis en forme à l'écran. Chaque structure hiérarchique de données possède un nom en relation avec son schéma de données, c'est-à-dire une liste de champs fortement typés, et un ensemble d'autres structures de données, 3061578 10 éventuellement de type différent. On rappelle que, dans des champs fortement typés, les variables ne sont pas dynamiques comme en JavaScript (marque déposée), elles ont un type strict (entier, chaîne de caractères, date). 5 Schéma de règles Le procédé de configuration utilise en second lieu un schéma décrivant les règles qui régissent une structure hiérarchique de données. Un schéma de règles est ici défini comme la description de la structure et de l'ensemble des règles qui définissent une structure hiérarchique de 10 données. Un schéma au format XSD peut être déduit d'un schéma de règles et peut ainsi être utilisé dans les échanges http sur un réseau de communications de données de type Internet. Dans un exemple non limitatif d'une partie du contenu d'un schéma de règles, on comprend qu'une variable d'un Type Complexe ici nommée « Toy » 15 est composée d'occurrences d'une variable d'un Type Complexe « Board ». L'ensemble d'occurrence des variables « Board » forme un ensemble de données. Cet ensemble de données peut être représenté sous forme de tableau. On peut maitriser cet ensemble d'occurrences aux travers de 20 contraintes, par exemple de valeur minimum ou maximum. Des règles d'inférences associées à chaque variable de type simple permettent de rendre la structure de données active aux changements de valeur. En effet la structure hiérarchique de données peut être associée à un moteur d'inférence qui permet la propagation et la résolution de l'induction provoquée par les deux 25 règles associées à chaque type simple. Une règle de changement fonctionne comme un évènement lors du changement de valeur d'une variable d'une structure de données hiérarchique, cette règle est donc une règle explicite. Il est à noter qu'il n'y a pas ici enchaînement en cascade comme en informatique (la règle modifiant à son 30 tour d'autres variables qui déclenchent à leur tour leur règle explicite), on respecte au contraire les pas du moteur d'inférence. Contrairement aux règles de définition (voir plus bas), une règle de changement ne s'exécute que si la valeur de la variable a été modifiée, elle ne tient pas compte des relations avec 3061578 11 les autres variables, dans les pas d'inférence la règle de changement est calculé avant les règles de définitions. Une règle de définition permet de définir la valeur d'une variable d'une structure de données hiérarchique, en fonction de son environnement. On 5 rappelle ici qu'une règle de définition est à la base de l'inférence, c'est une règle qui définit la valeur de la variable en fonction des autres variables. Contrairement à une règle de changement, une règle de définition est implicite (c'est à dire que, par exemple, dans l'égalité v1 = v2 - v3, si v2 change v1 doit être recalculé). Elle doit déterminer son cas d'emploi pour pouvoir s'exécuter 10 au moment opportun. Pendant un pas d'inférence toutes les règles sont calculées sur le même ensemble de valeur (équipotence entre les valeurs et le résultat), puis toutes les valeurs sont mises à jour, ainsi de suite jusqu'à la stabilisation de l'ensemble. 15 Identifiant unique de référence Un identifiant unique de référence (URI=Unique Reference Identifier) permet d'obtenir de manière unique une structure de données hiérarchique ou une donnée particulière dans une structure complexe. Cet identifiant unique de référence Uri est l'adresse de la variable dans une structure hiérarchique. Un 20 ensemble de règles d'écriture sur ces identifiants sont définies. Une méthode de recherche « Find » permet de retrouver un élément en fonction de son identifiant unique de référence, une syntaxe particulière permet de rechercher une structure hiérarchique de données en fonction de la valeur d'un de ses champs. Les identifiants uniques de référence servent principalement pour les 25 piles, l'association d'une entité graphique (TextBox) avec une variable du modèle ("Binding") et l'accès aux données dans les algorithmes complexes. L'identifiant unique de référence Uri sert à connaître l'adresse de la variable associée. Les algorithmes complexes sont des règles algorithmiques qui permettent de lier des structures entre elles, par exemple de transformer une 30 structure de données de configuration en une structure pour l'impression, etc. Une extension est éventuellement faite à une structure hiérarchique de données pour y ajouter un ou plusieurs index de recherche dans le cas d'ensemble conséquent de données, et pour s'appuyer sur la méthode connue 3061578 12 en soi « Link ». Outil de stockage de structures hiérarchiques de données Une structure hiérarchique de données, telle que définie précédemment, 5 est un ensemble de données qui ne peut persister qu'en mémoire. Pour pouvoir sauvegarder toutes les structure hiérarchique de données qui composent une configuration (une configuration est représentable comme un ensemble de collections de structures de données), on utilise, dans le présent procédé de configuration, un outil générique pour le stockage de ces 10 collections de structures de données en mémoire persistante. Cet outil générique est une collection de structures de données persistantes. Une collection de structures hiérarchiques de données est associée à un schéma de règles unique qui décrit le comportement de tous les éléments (structures hiérarchiques de données) de la collection. 15 Une collection de structures de données est également associée à un ensemble de fournisseurs de données (fournisseurs de contenus mis à disposition pour la réalisation de configurations) qui permettent le stockage physique de la collection en fonction de différentes stratégies de stockage. Une collection de structures de données doit-être stockée sur disque, en 20 base, dans des services de stockage délocalisés ("cloud"), ou autre suivant la stratégie, et chaque stratégie à son fournisseur (provider). Module de gestion graphique et d'exposition sur le Web ("service web") 25 Le procédé comporte en outre un module de représentation des données manipulées dans le module précédent, selon un format compatible avec un affichage sur des ordinateurs reliés à un réseau de type Internet. Dans un premier mode de réalisation, non limitatif, on utilise un service web qui respecte l'architecture REST (de l'anglais Representational State 30 Transfert), connue en soi. L'architecture REST utilise des standards, en particulier : - URI comme syntaxe universelle pour adresser les ressources, HTTP un protocole sans état (en anglais stateless) avec un 3061578 13 nombre très limité d'opérations, - Des hyperliens dans des documents (X)HTML et XML pour représenter à la fois le contenu des informations et la transition entre états de l'application, 5 - Les types MIME comme text/xml, text/html, image/jpeg, application/pdf, video/mpeg pour la représentation des ressources. De façon résumée, les données sont obtenues d'un service Web pour être liées (au sens du lien d'objets pour faire communiquer le modèle de données et la visualisation utilisateur - binding-) aux contrôles visuels. 10 Le procédé comporte également un service web en charge la persistance et la gestion des configurations en cours. Il est bâti autour d'une architecture de caches configurables, de manière à donner à ce service Web une grande fluidité d'utilisation. Ce service web contient des objets temporaires qui permettent l'exécution de différentes configurations, chacune est identifiée 15 par un ticket dont la durée de vie est gérée par une stratégie fonction de conditions spécifiques à l'application ou au client considérée. Le procédé utilise un ensemble de descriptions des collections de structures de données qui composent la configuration. Le procédé utilise en outre des descripteurs de collections de structures hiérarchiques de données partageant un même 20 schéma de règles (c'est à dire associées au même moteur d'inférence). Chaque collection de structures hiérarchiques de données possède son propre fournisseur de données clients. On rappelle qu'une collection doit-être stockée sur disque, en base, sur le Cloud, ou autre suivant la stratégie, et chaque stratégie à son fournisseur (provider). 25 Le procédé travaille sur un ensemble de variables de base (destinées à être accessibles à un utilisateur du configurateur). Une modification de la valeur d'une variable de base entraîne le démarrage du moteur d'inférence (le module de manipulation de données, c'est à dire le schéma de règles). Ce module permet de définir des règles dans les bases de données qui 30 provoquent un événement (exemple un ajout, une modification). Cet événement est lié au cache de données (mise à jour) ou au moteur d'inférence (modification d'une règle de définition). Par exemple, à titre de clarification, si la valeur d'un stock est modifiée, 3061578 14 les règles associées à la quantité restante sont mises à jour pendant la configuration. Une variable de base est associée à des contraintes définies dans le schéma et à des règles vérifiées par le moteur d'inférence. Certaines variables 5 de base sont associées à un paramètre qui définit leur ensemble des valeurs possibles. Le procédé conserve, dans le présent exemple non limitatif de mise en oeuvre, au moins une liste chronologique décrivant les variables de base modifiées par l'utilisateur ou le moteur d'inférence. Chaque variable de base 10 est décrite notamment par la localisation de la variable de base ainsi que sa valeur, ou par un ensemble de paires clef / valeurs possibles pour une variable de base, cette liste définit l'ensemble des valeurs possible d'une variable de base en fonction de l'état d'une structure hiérarchique de données. 15 Le procédé de création de configurateur Une configuration effectuée pour un client 22 (par exemple conception d'un portail de dimensions et géométrie spécifiques) est une suite d'opérations effectuées au sein d'un flux de données semblable à un flux de travaux (en anglais workflow). Certaines opérations sont de type logique et d'autres de 20 type graphique (formulaire). La demanderesse a constaté qu'en affinant la granularité, un grand nombre de formulaires présentent des fonctionnements similaires, seule change la logique permettant au client de gérer le schéma des règles de la structure hiérarchique de données. En partant de ces observations, le procédé de création de configurateur a pour objectif de 25 proposer un certain nombre de modèles d'opérateurs logiques et d'objets graphiques qui peuvent s'assembler au sein d'un flux paramétrable. Le procédé de création de configurateur utilise les données et fonctionnalités du module de manipulation de données, et sur les technologies connues sous les noms Wpf, Wcf, Wf. Le procédé de création de configurateur 30 en ligne s'appuie sur une architecture de type connu sous le nom de Multi-Tier (architecture à plusieurs niveaux), ce qui signifie que certains objets graphiques logiques sont hébergés dans des Services web. Le procédé de création de configurateur, décrit ici à titre d'exemple, offre un moyen de 3061578 15 générer un configurateur clients/Serveur d'une manière simple et accessible. Les modèles proposés doivent être souples pour répondre à toutes les configurations. Pendant une configuration complexe, il peut avoir plusieurs structures en inférence. Étant donné qu'il n'y a pas de données stockées sur le 5 terminal client 20, le procédé comporte des sessions de configuration sur le serveur associé, et à chaque modification de données le procédé fait un appel vers la session associée (cookie) qui infère et renvoie le résultat au terminal client 20. Dans une autre variante de mise en oeuvre du procédé, on appelle une règle de type WebRule qui injecte des données d'une session à une autre 10 en respectant un ensemble de règles, ainsi aucun calcul et aucune donnée ne se trouve stockée sur le terminal client 20 (selon une philosophie de "client léger"). Dans un mode de mise en oeuvre décrit ici à titre d'exemple non limitatif, les objets graphiques sont développés en langage Wpf, le paramétrage des 15 objets graphiques se fait par un simple push de composant et un lien des objets entre eux (binding) pour permettre la communication entre le modèle de données et la visualisation utilisateur) semi-automatique à la structure hiérarchique de données au sein du Studio (marque déposée). Dans une autre mise en oeuvre, ces structures hiérarchiques sont des 20 modèles de données (dynamiques). Pour les associer à un affichage, le procédé comprend un module de présentation de données. Ce module de présentation de données a pour fonction de présenter les données (couleur, langue du client, étiquette associé, type de contrôle), et de les modifier à l'aide d'un outil graphique dans le Studio (marque déposée). 25 A partir de ce module de présentation de données, on génère un affichage (frame) dans la technologie d'affichage utilisée (Xaml ou html5, ou autre à venir) en appliquant le lien des objets entre eux (binding). Pour lier tous les modules de présentation de données (associés chacun à une structure hiérarchique de données), le procédé met en oeuvre une étape 30 qui permet de naviguer d'un premier module de présentation de données à un second module de présentation de données, en suivant le processus désiré par le client. Dans cette étape, on s'assure du passage des identifiants de session, du retour au précédent et de la communication entre les modules de 3061578 16 présentation de données. L'affichage suit le flux des modules de présentation de données en activant la présentation ("trame") (formulaire ou userControl) associée. Le procédé utilise plusieurs types d'éléments distincts : 5 - environnement graphique de base, muni d'un menu interaction et d'un espace de travail contenant des objets graphiques. - objet graphique de base fourni dans une bibliothèque. - opérateur logique (objet de calcul) ayant une fonctionnalité précise - descripteur de commande, objet permettant (ou provoquant) la 10 transition du flux de données d'un objet graphique vers un autre objet graphique ou un opérateur logique. Une commande provoque au travers d'une règle le passage d'un module de présentation de données à un autre, ou l'appel d'une WebRule (calcul sur le serveur) - structure hiérarchique de données, objet permettant le stockage des 15 données fournies par les différents composants. Fonctionnement du procédé Le fonctionnement du procédé est illustré par l'organigramme de la figure 2. 20 Dans une première étape 110 de la phase 100 de création de configurateur logiciel, l'entreprise 32 procède à l'identification des variables permettant la définition des produits qu'elle veut faire configurer par ses utilisateurs (clients) 22. Dans une seconde étape 120, les règles d'inférence sont identifiées, puis dans une troisième étape 130, les modes de 25 représentation des variables sont définis. Le système procède alors, dans une étape 140, à une vérification de cohérence des règles d'inférence définies précédemment. Il génère alors, dans une étape 150, une interface visuelle destinée aux utilisateurs clients 22 du configurateur. Cette étape 150, qui est spécifique à la présente invention, sera décrite plus en détails en fin de 30 description. Dans une étape 160, des règles de fabrication sont définies par l'entreprise 32, sur la base des variables définies dans l'étape 110. Dans une étape 210 de la phase 200 d'utilisation du configurateur, le 3061578 17 système affiche, à destination de l'utilisateur client 22, au moins une partie d'un schéma de données. Puis l'utilisateur client 22 vient modifier des données en fonction de ses besoins propres, et le moteur d'inférence propage les modifications aux autres 5 variables liées par des règles d'inférence. Plus précisément, lors du fonctionnement du moteur d'inférence, le moteur passe à travers plusieurs états qui s'enchainent de manière cyclique jusqu'à la stabilisation de l'ensemble de données ou à la détection de la récurrence de données cycliques. 10 Dans une première étape 220, le système est en attente de modifications de la part d'un utilisateur client 22 du configurateur. Lors de la réception d'une telle modification, dans une étape 222, le système exécute les règles de changement pertinentes. Les règles de changement sont exécutées pour toutes les valeurs se trouvant dans la pile de 15 modification, chaque règle de changement peut changer d'autres données qui sont à leur tour stockées dans la prochaine pile de modification. Puis dans une étape 224, le système recherche les cas d'emploi des règles de définition. La recherche des cas d'emploi se fait en plusieurs états : dans un premier temps toutes les règles de définitions sont exécutées pour 20 déterminer les données utilisées pour chaque règle, par la suite ne sont exécutées que les règles liées aux valeurs modifiées. Il exécute alors dans une étape 226 les règles de définition pertinentes. Les règles de définitions sont exécutées en fonction de la pile de modification et des cas d'emploi. Chaque règle de modification met à jour la donnée 25 concernée qui vient s'ajouter dans la pile de modification si celle-ci est réellement différente de la valeur précédente. Puis le système met à jour, dans une étape 228, l'ensemble des données. Toutes les données modifiées sont stockées dans une pile de modification avant d'être mémorisées et comparées à un historique des 30 données. Cette pile de modification sert pour éviter que l'ensemble des données soit modifié pendant l'exécution des différentes règles. Chaque règle est exécutée à partir du même ensemble de définition, ce qui évite le problème d'exécution de code sur un ensemble de données en modification. 3061578 18 Lorsque ces données sont stabilisées, la nouvelle configuration est affichée dans une étape 230 sur l'interface utilisateur. La stabilisation de l'ensemble de données est obtenue quand il n'y a plus de données modifiées (variation inférieure à un seuil prédéterminé). Dans le cas de cycle (données ne 5 convergent pas vers un ensemble de valeurs, mais revenant régulièrement sur un même jeu de valeurs) une autre stratégie est déployée en tenant compte de l'historique des modifications. Pour détecter les cycles, on recherche, lors de la mise à jour des données, si un ensemble identique a existé dans le passé. Dans ce cas, des règles de choix, préalablement entrées par l'entreprise 32, 10 sont utilisées pour la détermination du meilleur ensemble de données parmi les ensembles revenant régulièrement lors de l'exécution du moteur d'inférence. Dans une étape 240, le système génère les données de fabrication du produit défini par l'utilisateur client 22 et correspondant à ses besoins et contraintes propres. 15 Enfin, dans une étape optionnelle 250, le système transfère des données de calcul à un serveur de type ERP 30 de l'entreprise 32. Le principe de fonctionnement du procédé décrit ici se distingue de l'art antérieur dans lequel on regarde une configuration comme l'ouverture d'une 20 fiche au travers de code se trouvant derrière des boutons. On imagine qu'une configuration est un flux applicatif dont la donnée est transportée par des structures hiérarchiques de données et le changement d'état (objet graphique ou opérateur logique) provoqué par des commandes. Dans le procédé décrit ici, les flux peuvent se multiplier et fusionner dans 25 certain opérateur logique, ce qui donne la possibilité d'avoir plusieurs états en même temps, c'est-à-dire plusieurs objets graphiques à la fois. On observe sur ce graphique le flux de déroulement de la configuration, L'objet graphique passe la main à l'opérateur logique au travers d'une commande, éventuellement soumise à des droits utilisateur. 30 Le procédé utilise un environnement graphique de base qui héberge tous les autres composants, il est formé de trois zones : - un bandeau d'affichage interactif et contextuel, - un objet de présentation sous forme d'onglet, et 3061578 19 - un espace de travail qui héberge les différents objets graphiques. L'environnement graphique de base est optimisé pour fonctionner aussi bien sur un poste de travail que dans un explorateur internet. L'environnement graphique de base n'est pas obligatoire dans une 5 configuration, mais il est souvent l'objet de démarrage, et il contient les commandes de bases qui démarrent le flux applicatif. L'environnement graphique de base héberge des objets graphiques de base. Chaque tel objet graphique contient un espace de travail, et une partie de ruban (un ruban est un élément d'interface utilisateur qui remplace ou 10 complète les boutons des menus connus précédemment et permet de regrouper des commandes associées pour les retrouver plus facilement) qui complètera le ruban de l'environnement graphique de base. Il existe une bibliothèque d'objets graphiques spécialisés (saisie de données, recherche, ...), un outil est proposé pour la conception d'un objet 15 graphique, celui-ci étant associé à une structure hiérarchique de données, qui lui sert de contexte et une collection de structures hiérarchiques de données (associée à un schéma de règles unique) pour l'accès aux données, un mécanisme simple de push de composant est proposé au concepteur avec le minimum de variable de paramétrage. 20 Le ruban associé à l'objet graphique est un assemblage de groupe et de descripteurs de commandes qui permet de respecter le mécanisme MVC (Modèle Vue contrôleur, en anglais "Model View Controler") et ce sont les commandes associées à chaque bouton qui permettent de naviguer d'objet graphique en objet graphique. On rappelle que MVC est une méthode de 25 conception d'interface homme-machine de logiciel. Dans cette méthode, l'interface homme-machine comporte d'une part un modèle de données, d'autre part une interface visuelle, enfin un contrôleur de logique des évènements. Il est clair que, dans des variantes de mise en oeuvre, le procédé peut également utiliser d'autres méthodes que MVC pour naviguer entre les objets 30 graphiques. Les objets graphiques sont spécialisés pour résoudre des problèmes spécifiques, mais restent paramétrables au travers des règles associées à leur structure hiérarchique de données, et aménageables au travers de StackPanel 3061578 20 de Microsoft -marques déposées- (commande permettant de réorganiser des éléments secondaires dans une hiérarchie d'éléments, sur une seule ligne pouvant être orientée horizontalement ou verticalement) qui sont enrichies de composants par des actions de glisser / déposer d'éléments disponibles de la 5 structure hiérarchique de données, sous forme de contrôle. Chaque opérateur logique (objet de calcul) est un composant de liaison entre deux objets graphiques ou opérateurs logiques. On peut citer, par exemple mais non limitativement, des opérateurs logiques du genre envoi d'un mail, écriture dans un fichier, recherche d'information dans un Web Service. 10 Une bibliothèque d'opérateurs logiques est fournie dans le procédé. Cette bibliothèque d'opérateurs logiques évolue dans le temps. La donnée traitée dans un opérateur logique est une structure hiérarchique de données, et la poursuite du flux se fait au travers de commandes qui sont exécutés par des déclencheurs ou des conditions 15 programmables. Dans l'exemple simple de création d'une nomenclature dans un logiciel de planification des ressources de l'entreprise (ERP), il existe un opérateur logique spécialisé pour cette opération, la structure hiérarchique de données en entrée est un extrait de la configuration, l'opérateur logique possède sa 20 propre structure hiérarchique de données de nomenclature. Une injection d'une structure hiérarchique de données a lieu pour la création de la nomenclature dans l'ERP. L'injection est le terme que l'on emploie pour transférer des données d'une structure à une autre. A titre de clarification, on peut avoir une structure complexe pour la configuration d'un 25 objet, et venir injecter le résultat (données significatives) dans une autre structure (une occurrence de devis par exemple). Une fois l'opération terminée, une commande est déclenchée pour la poursuite du flux. Le procédé utilise un ensemble de descripteurs de commande. Chaque 30 commande est associée à une image, un état, une description et une implémentation. Les descripteurs de commande sont regroupés dans un gestionnaire de commande indépendant. Au sens du présent procédé, un descripteur de commande utilise en entrée le contexte de l'objet graphique 3061578 21 courant et fournit un contexte à l'objet graphique suivant. Comme les objets graphiques peuvent s'empiler dans certaines configurations, certaines commandes provoquent la simple fermeture d'un objet graphique. Pour clarifier la notion d'empilement des objets graphiques, on note que 5 dans le procédé, on a un système de navigation dans lequel l'utilisateur peut avancer dans le processus, mais aussi revenir en arrière, ou au départ. On a donc un fil d'Ariane (ou empilement) composé de module de présentation de données, et certaine commande permette de manipuler ce fil, (suivant, retour, fin, revenir au début, ...) 10 Une commande peut-être l'ouverture d'une fiche client, la commande doit extraire le code du client du contexte courant pour positionner l'objet graphique édition du client sur la bonne personne. Le transport des données dans le flux se fait au travers de structures (ou conteneurs) hiérarchiques de données, les données peuvent transiter soit par 15 la mémoire, soit au travers de collections persistantes de structures hiérarchiques de données. L'étape 150 de création de l'application client (configurateur de produits) proprement dite fait l'objet de la présente invention. L'architecture du metaconfigurateur est formée par un enchainement entre un système expert d'aide 20 à la génération d'applications et un générateur d'applications proprement dit. L'application générée peut être visualisée en temps réel et testée. Il est alors possible au développeur de l'application de reboucler sur le système experts d'aide à la génération d'application de façon à faire évoluer l'application de façon itérative. 25 Dans le présent exemple de réalisation, on entend par application un logiciel accessible par un réseau de type Internet à des utilisateurs 22 dotés d'un environnement de travail de type PC. L'architecture du système expert d'aide à la génération d'application est présentée Figure 3. 30 Ce système expert se présente sous la forme d'une application Web, son but est de consolider la base de connaissances qui sert à la génération de l'application client (configurateur de produits) en s'appuyant sur des règles métiers définies. L'application web client est fabriquée en deux temps : le jeu 3061578 22 de questions/réponses et la génération de l'application pour test. Le générateur d'application web (configurateur de produits) est présenté Figure 4 et s'appuie sur la base de connaissance construite par le système expert, pour générer tous les objets qui permettront de compiler et de publier 5 l'application Web client. On rappelle qu'on est ici dans la phase 100 de création de l'application (configurateur) par une entreprise 32, avant l'utilisation de ce configurateur par un ou plusieurs utilisateurs 22, qui sont eux-mêmes des clients de l'entreprise 32. 10 De façon générale, dans l'étape 150, le système pose une série de questions au développeur chez le client 32, de manière à identifier une logique de comportement propre au métier de l'entreprise 32. Ces questions forment une arborescence et leur choix et enchainement est réalisé par le système de manière dynamique en fonction des réponses aux questions précédentes. 15 Ensuite, sur la base de règles de développement d'application web préalablement entrées en mémoire et formant des règles métier du développement d'une application web, le système configure des briques logicielles en les adaptant à chaque entreprise 32, de manière à générer une application client par assemblage de ces briques logicielles. Le système 20 détermine ainsi, par exemple, le nombre d'écrans d'affichage nécessaire, puis configure chaque page écran de façon interactive avec le développeur. L'application client finalement générée est un configurateur de produit spécifique à l'entreprise 32, dont le but est de faire gagner du temps lors de la configuration d'un produit pour un utilisateur client 22, et de permettre de 25 générer rapidement et sans erreur des éléments de production tels que des côtes de fabrication du produit. Dans le présent exemple de réalisation, et ainsi qu'il est illustré figure 5, l'étape 150 de génération d'interface IHM comporte un ensemble de sous-étapes décrites ci-dessous. 30 3061578 23 Sous-étape 1501 : Initialisation du questionnaire Le procédé (meta-configurateur) crée une instance de configurateur qui permet de faire un échange de questions /réponses entre un développeur de l'entreprise 32 et le serveur 15 : 5 a. Connexion https de l'entreprise 32 sur le serveur 15 hébergeant l'application logicielle mettant en oeuvre le procédé, b. Le serveur 15 va créer une instance de configurateur de la manière suivante : i. Création d'un objet configurateur en mémoire sur le 10 serveur 15, ii. Lecture dans la base de données des règles métiers préalablement identifiées dans les étapes précédentes du procédé, iii. Chargement des règles métiers en mémoire, 15 iv. Exécution des règles métiers pour créer un arbre de dépendance sur les règles métiers, (Les points ii à iv font l'objet de la demande FR 2 999 314 Al et sont rappelés dans les pages précédentes) v. A l'issue du premier calcul des règles métiers, le serveur 20 15 renvoie la première question sous forme de modèles de données vers le développeur de l'entreprise 32 : { Question : { 25 Numero : « 1 », Nom : « XXX » TypeQuestion : « Boolean_ChoixSimple » } } 30 vi. Le serveur 15 renvoie également les ressources nécessaires à l'affichage d'une page web (fichier Css pour la mise en oeuvre, JS pour l'interaction Utilisateur/Page, Code Html, Fichiers images) 3061578 24 c. Le développeur de l'entreprise 32 reçoit les données issues du serveur 15 puis les interprète pour construire un affichage en HTML. 5 Sous-étape 1502 : Réception et analyses des réponses Le configurateur reçoit une réponse N°, chaque répcnse va entrainer le lancement d'un moteur de règle (voir la demande FR 2 999 314 A1) pour proposer une question N+1 adapté à l'environnement que l'utilisateur est en train de définir par ses précédentes réponses, 10 a. Le développeur de l'entreprise 32 saisit une réponse à la question qui lui est proposée, b. Le navigateur intercepte la réponse pour la transformer en modèle de réponse à la question : { 15 Reponse : { QuestionNumero : 1 ValeurReponse : true } 20 } c. Il envoie cette réponse au serveur par une requête http (ajax) d. Le serveur reçoit la réponse et insère dans l'objet configurateur serveur la réponse reçue, e. Ce changement de valeur fait tourner un moteur d'inférence basé 25 sur l'arbre de dépendance créé lors de l'étape (1 - b - iv) pour recalculer les règles métiers, f. Le recalcul amène deux changements sur l'objet configurateur du serveur, il permet de construire un objet Question (N+1) et il met à jour l'arbre des dépendances du serveur pour cette 30 configuration, g. Le serveur renvoie la question N+1 au développeur de l'entreprise 32, 3061578 25 h. Le mécanisme se répète jusqu'à ne plus avoir de questions à proposer au développeur de l'entreprise 32, Exemple : Si la première question est : 5 L'application demandera-t-elle une authentification ? Si la réponse est oui : La question n° 2 sera : Est-ce une authentification par : - Login/mot de passe - Active Directory 10 - Site tiers (Single Sign On) Si la réponse est non : La question n°2 sera : Est-ce que l'application sera accessible depuis Internet ? (Oui /Non) Ce principe de questions / réponses permet de : 15 - Proposer des questions adaptées au contexte de l'entreprise 32 - Avertir l'utilisateur sur ces réponses quand elles présentent une incohérence (ex : Application sur internet sans accès avec affichage de la marge 20 produit) - Créer une application unique et personnalisée : il ne s'agit pas d'un choix entre plusieurs applications prédéfinies mais bien d'une construction d'application par le déroulement de 25 plusieurs centaines de règles métiers de configuration. Sous-étape 1503 : Pré visualisation / Construction de l'application web / Déploiement 30 À tout moment du processus de questionnement, le développeur de l'entreprise 32 peut demander la prévisualisation de l'application afin de confirmer que le configurateur qui sera produit est conforme à ses attentes. 3061578 26 Le mécanisme de prévisualisation se déroule de la manière suivante : a. Le développeur de l'entreprise 32 appui sur un bouton de demande de prévisualisation, b. L'appui sur ce bouton déclenche une requête http sur le serveur 5 15 hébergeant le logiciel mettant en oeuvre le procédé de génération de configurateur, c. La requête de demande de prévisualisation reçue, le configurateur charge un jeu de règles métiers dédiés à la génération de code source html. Les règles métiers chargées se 10 décomposent en plusieurs catégories : i. Des règles spécialisées dans la navigation entre page, ii. Des règles spécialisées dans la construction visuelle des pages, iii. Des règles spécialisées dans la partie métier des pages, 15 iv. Des règles spécialisées dans la partie base de données de l'application, v. Des règles spécialisées dans la partie Compilation Informatique, d. L'exécution des règles métiers de génération va ainsi permettre 20 de définir des structures complètes de fichiers de code sources informatiques ainsi que tout un environnement de compilation, e. La compilation se fera par un outil tiers fourni par le créateur du langage informatique utilisé, f. Le résultat de la compilation sera copié dans un répertoire 25 temporaire généré aléatoirement par code informatique, g. De façon programmatique, une structure d'hébergement web sera créée i. Création d'un pool d'application avec une identité prédéfinie (fichier de configuration) (La base site web sera 30 déjà créée) 3061578 27 Avantages Le méta configurateur qui constitue le procédé décrit plus haut, est un outil générique de création d'application métiers de gestion de configurateurs métiers (protocoles générés, gérés et intégrés automatiquement) pour l'aide à 5 la vente et l'administration de données produits manufacturés ou de "produits services" pour « concevoir une application métiers à la demande » (génération de code automatique) au service des et pour les clients Marketing de marché des consommateurs. L'idée est ici de créer un configurateur d'application pour la création de 10 tous les éléments formant une application web de configurateur de produits d'une entreprise 32 vers ses utilisateurs clients 22. De cette manière, non seulement l'utilisateur client 22 peut configurer son produit de façon très simple et ludique sans aucune connaissance en informatique, mais il en est de même de l'entreprise 32, qui utilise le configurateur d'application pour développer 15 chaque configurateur spécifique à ses produits, sans connaissance particulière en développement de site internet. Par ailleurs, ce site est aisément visualisable tout au long de la création d'un configurateur de produits par l'entreprise 32, et est aisément modifiable par ladite entreprise 32, de façon exactement analogue au produit que l'utilisateur client 22 configure selon ses 20 besoins grâce au configurateur, de façon également visualisable et modifiable tout au long de sa création. Ce procédé de génération d'un configurateur de produit, ledit procédé constituant en soi un méta-configurateur (configurateur d'une application formant configurateur de produits), permet de concevoir et de générer des 25 applications métiers produits à la demande (sans connaissance informatique particulière). Il permet de générer graphiquement des données hiérarchiques métiers, les formulaires et workflow logiciel (enchainement de formulaire par interaction utilisateur) pour des applications métier variées de gestion de configurateurs en services "Business-to-Business ou Business-to-Customer" 30 (par exemple tels que des configurateurs CPQ- Configure, Price and Quote). Le méta-configurateur ici décrit est un générateur interactif d'application web cliente qui permet par exemple la définition automatique de côtes de fabrication de pièces sur-mesure, en tenant compte de règles métier 3061578 28 concernant la cohérence de ces côtes ou autres caractéristiques. Il constitue un système de conception assistée par ordinateur et permet d'accélérer et d'optimiser la fabrication de pièces qui peuvent prendre des configurations multiples selon des besoins spécifiques d'utilisateurs. 5 Les fonctionnalités du méta configurateur interactif permettent de générer et d'éditer sur une plateforme HTML5, des applications de gestion de configurateurs métiers destinés à la vente en ligne (e-commerce) indépendant des navigateurs et des matériels utilisés. Il permet de concevoir des applications qui vont offrir des services en 10 ligne incluant la gestion de projets, la gestion de client, la gestion d'appel d'offres, la gestion de tableau d'affichage (DashBoard), la gestion du workflow décisionnel (validation de projet ou d'offres) quantifiables en temps réel en fonctions des choix des variantes et des options retenues par les utilisateurs clients des compagnies utilisatrices de la plateforme. 15 Ce progiciel est proche du Standard CIM (Common Information Model) en ce sens qu'il définit comment des éléments administrés dans un environnement produits manufacturés et industriels (ERP) peuvent être représentés sous forme d'un ensemble d'objets cohérents et d'un ensemble de relations entre ces objets. Le but est d'avoir une administration et une gestion 20 de configuration produit cohérente et unifiée des éléments produits à options et variantes gérés, et cela de façon totalement générique par rapport aux produits, fabricants ou fournisseurs. Le schéma CIM est un schéma conceptuel qui définit comment administrer des éléments dans un environnement informatique. Ce schéma 25 permet de représenter des éléments comme un ensemble d'objets et de relations entre eux. Le procédé décrit plus haut présente plusieurs avantages : - Création d'une application web depuis une interface web, - Déploiement d'une application web sans avoir besoin de connaissances et d'outils informatiques, 30 - Application construite sur mesure en fonction des réponses formulées, - Les questions proposées à l'utilisateur ne sont pas nécessairement des questions fermées, 3061578 29 - Il s'agit d'un configurateur de configurateur, le produit fini sera une interface web encapsulant un configurateur de produit qui pourra lui-même évoluer par la suite. REVENDICATIONS1. Procédé de création d'un simulateur logiciel d'un produit pouvant être configuré selon différentes variantes selon des données définissant les besoins et contraintes d'un utilisateur client (22), ledit procédé étant destiné à être mis en oeuvre par un ordinateur (20) 5 comportant des moyens de communication à un réseau d'échange de données de type Internet, ledit simulateur logiciel comportant une interface homme-machine, comportant : - un modèle de données, 10 - une interface visuelle, - un contrôleur de logique des évènements, ledit procédé comportant des premiers moyens graphiques de définition de liens logiques entre les données, pour permettre à un développeur d'une entreprise (32) de développer ledit simulateur logiciel sans écrire directement 15 de code informatique, le contrôleur logique des évènements imposant des relations entre les données du modèle et les éléments de la visualisation selon un ensemble paramétrables de règles dites "règles métier", définies par des seconds moyens graphiques de définition de liens logiques entre les données, 20 caractérisé en ce que le procédé comporte une étape 150 de génération de l'interface homme-machine dans laquelle un système informatique pose une série de questions au développeur de l'entreprise (32), de manière à déterminer une logique du comportement d'un client lors du choix et de la définition d'un produit au cours de l'utilisation du simulateur logiciel, puis, sur la 25 base de règles de développement d'application web préalablement entrées en mémoire et formant des règles métier du développement d'une application web, le développeur de l'entreprise (32) configure des briques logicielles proposées par le système en tenant compte de la logique du comportement déterminée, en adaptant ces briques logicielles à l'entreprise (32), de manière 30 à générer un simulateur logiciel par assemblage de ces briques logicielles. 3061578 31 2. Procédé selon la revendication 1, caractérisé en ce que les questions de l'étape 150 forment une arborescence et leur choix et enchainement est réalisé par le système de manière dynamique en fonction des réponses 5 apportées aux questions précédentes. 3. Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce que le module de définition de règles métier comporte des règles de cohérence applicables à ces règles métier, de manière à mettre en évidence 10 les conflits éventuels entre certaines de ces règles lors de leur génération par le développeur de l'entreprise (32).