FR 2947355 A1 20101231 FR 0954307 A 20090624 La présente invention concerne l'échange de données entre des applications logicielles et plus particulièrement un procédé et un dispositif d'intégration d'applications hétérogènes. S'il existe des éditeurs d'applications logicielles proposant des suites complètes d'applications pour entreprises, ces éditeurs sont généralement spécialisés par domaines. Ainsi, par exemple, il existe des éditeurs proposant des applications de gestion de la relation client, aussi appelées CRM (sigle de Customer Relationship Management en terminologie anglo-saxonne), d'autres proposant des applications de gestion des offres commerciales et de facturation ou d'autres encore proposant des applications d'activation de services, par exemple d'activation de cartes SIM (sigle de Subscriber Identity Module en terminologie anglo-saxonne). Alors que ces applications sont indépendantes les unes des autres, certaines données sont utilisées par plusieurs applications distinctes et certaines données produites par des applications particulières sont utilisées par d'autres. De la même façon, il est possible que certaines routines ou instructions d'une application doivent être exécutées après d'autres routines ou instructions exécutées par d'autres applications. De façon similaire, certaines règles peuvent être utilisées par plusieurs applications. Ainsi, à titre d'illustration, lorsqu'un client souscrit un nouveau contrat de service de téléphonie, ses références sont saisies dans une application de gestion de la relation client. Certaines des informations saisies sont ensuite saisies à nouveau dans une application de gestion de compte et de valorisation pour gérer le compte du client et déterminer sa consommation ainsi que ces droits afin de permettre sa facturation. Ces différentes applications étant souvent développées sur des plateformes informatiques différentes, elles ne sont pas compatibles les unes avec les autres. En outre, elles peuvent être distribuées dans un réseau informatique. Ainsi, lorsque plusieurs applications nécessitent les mêmes données, il est souvent nécessaire de les saisir plusieurs fois. La transmission des données entre les différentes applications peut être manuelle. A titre d'illustration, la figure 1 a représente deux systèmes informatiques distincts. Le premier système informatique est ici utilisé pour mettre en oeuvre une application 100 de gestion de la relation client tandis que le second système informatique est ici utilisé pour mettre en oeuvre une application 105 de facturation. Comme illustré par la référence 110, certaines données sont transmises à chacune des applications 100 et 105. De telles données sont, par exemple, des données relatives aux clients. De la même façon, d'autres données sont également transmises à chacune des applications 100 et 105 (référence 115). Ces données peuvent notamment être des données relatives aux contrats proposés aux clients. Par ailleurs, comme illustré par la flèche 120, il peut être nécessaire de recopier des données générées par l'application 100 de gestion de la clientèle dans l'application 105 de facturation. Ces données sont, par exemple, des références clients. L'utilisation de flèches en trait pointillé indique ici des opérations manuelles. Pour éviter une ressaisie ou une double saisie des données entre ces applications, il est donc nécessaire de prévoir une interface entre ces applications. Des solutions simples pour interfacer un nombre limité d'applications hétérogènes consistent à développer un système tiers qui transmet les données, les règles et/ou les commandes aux applications hétérogènes dans leur format particulier. La figure 1 b illustre un tel exemple. Selon cet exemple, le système informatique 125 est utilisée pour saisir toutes les données (référence 130) qui sont converties dans le format spécifique aux applications 100' et 105' de gestion de la relation client et de facturation, respectivement, afin d'être automatiquement transmises à celles-ci (référence 135). Ainsi, les données ne sont saisies qu'une seule fois. Cependant, de telles solutions sont spécifiques aux applications hétérogènes mises en oeuvre. Par conséquent, elles sont difficilement adaptables à d'autres situations similaires. De plus, la mise à jour de l'une des applications hétérogènes requiert généralement la mise à jour de l'application tierce. Selon une autre solution, une couche intermédiaire, aussi appelée intergiciel ou middleware en terminologie anglo-saxonne, est utilisée. Une telle couche a essentiellement pour objet de convertir le format des données pour permettre leur échange et de gérer les appels des fonctions de ces applications. Sur cette base, des solutions plus évoluées peuvent être développées pour modéliser les processus mis en oeuvre et les échanges de données entre les applications. De telles solutions sont notamment les EAI (sigle d'Enterprise Application Integration en terminologie anglo-saxonne) et ESB (sigle d'Enterprise Service Bus en terminologie anglo-saxonne). Les EAI sont des architectures permettant à des applications hétérogènes de collaborer dans le cadre de l'intégration métier. De façon générale, un EAI comprend des connecteurs utilisés comme interfaces avec les applications, des modules de mise en correspondance pour transformer les données spécifiques reçues en données normalisées et réciproquement, ainsi que des modules d'échange pour acheminer les données entre les applications. La figure 1c illustre un exemple simplifié de la mise en oeuvre d'une plateforme EAI 140 permettant de relier une application 100" de gestion de la relation client et une application 105" de facturation. Des données de l'application 100" sont transmises (référence 145) à la plateforme EAI 140 sous forme de messages. Plus précisément, les données sont généralement transmises à un module 150 ayant pour fonction de vérifier le format du message, en fonction d'un schéma prédéterminé, et d'extraire les données. Les données sont ensuite redirigées dans un premier module de conversion 155 pour être organisées selon une structure propre à l'EAI (référence 160), appelée schéma pivot, permettant un traitement des données indépendant des applications 100" et 105". Les données conformes au schéma pivot sont alors transmises à un second module de conversion 165 pour être réorganisées selon la structure requise par l'application 105". L'étape de conversion peut également comprendre une étape d'enrichissement. Cette dernière est réalisée à partir de données ou de règles de transformation mémorisées dans l'EAI, par exemple dans la base de données 170. A titre d'illustration, lorsque les données relatives à un client sont transmises de l'application 100" à l'application 105", il est généralement nécessaire de convertir les données en fonctions de paramètres spécifiques à l'application 105", notamment de paramètres liés à la qualité des clients (par exemple, la qualité du client, particulier ou professionnel, peut avoir une influence sur les contrats qui lui sont proposés et sur la facturation.). Enfin, avant d'être transmises sous forme de message (référence 180), les données sont formatées dans le module 175 selon un format prédéterminé, lié à l'application 105", défini par un schéma. Bien qu'une telle solution présente de nombreux avantages, notamment en termes d'intégration de nombreuses applications, elle est néanmoins complexe et a un coût de mise en oeuvre souvent très important lié, en particulier, aux besoins de connaissances métiers et de connaissances des applications. De plus, en raison de l'intégration de la combinaison des connaissances métiers et des connaissances des applications hétérogènes, une solution EAI développée pour un contexte particulier est difficilement portable dans un autre contexte. Les ESB, reprenant la philosophie des EAI, sont orientés services (leur architecture est dite SOA, sigle de Service Oriented Architecture en terminologie anglo-saxonne). Ils sont basés sur les services web et l'échange de messages. Si ces solutions sont plus facilement généralisables, elles sont également complexes à mettre en oeuvre. Il existe donc un besoin pour des solutions simples, faciles à mettre en oeuvre, dont le coût de développement est limité et pouvant être réutilisées pour interfacer un nombre limité d'applications hétérogènes, notamment dans le domaine de la gestion des contrats de téléphonie, fixe ou mobile, et de communication par réseau de type Internet. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé d'ordinateur pour l'intégration d'applications hétérogènes dans un système comprenant au moins deux applications hétérogènes, ce procédé comprenant les étapes suivantes, - réception d'au moins une première donnée d'une desdites au moins deux applications hétérogènes selon un format spécifique à ladite une desdites au moins deux applications hétérogènes ; - conversion de la dite au moins une donnée reçue selon un format de donnée prédéterminé distinct des formats de données utilisés par lesdites au moins deux applications hétérogènes ; - réception d'au moins une seconde donnée de l'autre desdites au moins deux applications hétérogènes ; - création d'un objet comprenant ladite au moins une première donnée reçue convertie dans ledit format de donnée prédéterminé, ladite création étant réalisée selon ladite au moins une seconde donnée reçue, ledit objet pouvant être traité directement par ladite autre desdites au moins deux applications hétérogènes ; et, - transmission dudit objet créé à ladite autre desdites au moins deux applications hétérogènes. Le procédé selon l'invention permet ainsi l'échange de données entre applications hétérogènes sans nécessiter de règles spécifiques de traitement de données liées à l'une des applications. Le procédé selon l'invention s'adapte donc à l'évolution de ces applications et des données traitées. En outre, il peut être facilement adapté à différentes applications hétérogènes. Les données reçues par l'une des applications hétérogènes peuvent être traitées directement, de façon standard. De façon avantageuse, le procédé comprend en outre une étape de vérification d'un contexte basé sur la comparaison de ladite au moins une première donnée reçue avec au moins une autre donnée reçue de ladite autre desdites au moins deux applications hétérogènes, distincte de ladite au moins une seconde donnée. Le procédé selon l'invention permet ainsi d'effectuer des vérifications avant de transmettre des données à une application, cette vérification étant basée sur des données propres à l'application devant les recevoir. Selon un mode de réalisation particulier ledit format prédéterminé à une structure récursive de telle sorte que le procédé est adapté à traiter des données d'applications hétérogènes lorsque la structure de ces données évolue. Pour traiter de telles structures récursives, sans restriction liée à celles-ci, le procédé comprend, de préférence, au moins une itération. Toujours selon un mode de réalisation particulier, ladite étape de création dudit objet comprenant ladite au moins une première donnée reçue convertie dans ledit format de donnée prédéterminé, ladite création étant réalisée selon ladite au moins une seconde donnée reçue, comprend une étape d'insertion de ladite au moins une seconde donnée dans ledit objet. Toujours selon un mode de réalisation particulier, le procédé est accessible à ladite une desdites au moins deux applications hétérogènes sous forme de services web. Le procédé peut ainsi être intégré dans un environnement standard et y être facilement accessible. Le procédé peut également accéder à ladite autre desdites au moins deux applications hétérogènes par une interface spécifique de ladite autre desdites au moins deux applications hétérogènes pour transmettre des données reçues et traitées conformément à l'invention lors de la sollicitation du procédé. Toujours selon un mode de réalisation particulier, ladite une desdites au moins deux applications hétérogènes est une application de gestion de la relation client, l'autre desdites au moins deux applications hétérogènes étant une application de facturation et/ou d'activation de services. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes de ce procédé. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1, comprenant les figures la, lb et 1c, représente schématiquement des solutions de l'art antérieur pour permettre l'échange de données entre des applications hétérogènes ; - la figure 2 illustre schématiquement un exemple de structure générique du format pivot utilisé dans une couche d'intégration conforme à l'invention ; - la figure 3 représente le transfert d'informations, d'un point de vue fonctionnel, entre une application de gestion de la relation client et une application de facturation, conformément à l'invention ; - la figure 4 illustre un exemple d'algorithme mis en oeuvre dans la couche d'intégration d'applications hétérogènes pour effectuer le transfert d'informations illustré sur la figure 3 ; - la figure 5, comprenant les figures 5a et 5b, illustre plus précisément un exemple de mise en oeuvre des fonctions de validation de contexte et de restructuration illustrées sur la figure 4 ; - la figure 6 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment les algorithmes représentés sur les figures 4 et 5. L'invention vise l'échange d'informations entre des applications hétérogènes. Elle a notamment pour objet d'établir une correspondance entre les données manipulées, de façon fiable et robuste, d'introduire des données nécessaires et non fournies en entrée et de permettre d'effectuer des transactions entre ces applications. Bien qu'elle puisse être mise en oeuvre entre de nombreuses applications, il est ici considéré, à des fins d'illustration, qu'elle est mise en oeuvre entre une application de gestion de la relation client et une application de facturation. Une application de gestion de la relation client a pour objet, en particulier, de cibler les clients afin de mieux les comprendre pour adapter et personnaliser les produits et/ou les services qui leur sont proposés et individualiser les relations. Une telle application permet donc de traiter toutes les informations relatives aux clients telles que son identité, son profil d'utilisateur et de consommateur de produits et/ou de services sous forme d'une base de connaissance sur la clientèle. Le profil comprend par exemple le moyen de paiement utilisé et les besoins du client. Par ailleurs, une application de facturation doit gérer certaines informations relatives aux clients pour permettre de les identifier, de connaître les termes de leurs contrats ainsi que leur consommation afin d'établir une facture. Ainsi, comme indiqué précédemment, certaines données sont communes aux applications de gestion de la relation client et de facturation. En outre, certaines données utilisées par l'une des applications dépendent de données gérer par l'autre application. En d'autres termes, le module d'intégration se charge de transformer les notions CRM telles que des informations relatives aux contrats et aux produits proposés en notions de facturation telles que des informations de souscription, services et charges de valorisation. Selon un mode de réalisation particulier, l'invention est mise en oeuvre sous la forme d'une module d'intégration, appelée integration layer en terminologie anglo-saxonne. Elle peut être mise en oeuvre de façon purement logicielle ou mixte, logicielle et matérielle, par exemple sur un serveur dédié. Toujours selon un mode de réalisation particulier, le module d'intégration est développé dans un langage de type ouvert, par exemple en langage Java conforme aux spécifications J2EE (Java et J2EE sont des marques). A titre d'illustration, le module d'intégration est ici basé sur le serveur d'applications JonAS (sigle de Java OpeN Application Server en terminologie anglo-saxonne). Le module d'intégration peut être décomposé en couches, chaque couche formant une interface avec une des applications hétérogènes à intégrer. Ainsi, par exemple, une couche peut avoir pour objet de recevoir les données d'une première application et de les transformer dans un format générique tandis qu'une second couche reçoit des données d'une seconde application, transforme les données mémorisées sous forme générique dans le format requis par la seconde application en les adaptant selon des données reçues de la seconde application et les transmet à cette dernière. De façon avantageuse, plusieurs formats génériques, aussi appelés formats pivot, sont définis dans le module d'intégration. Cependant, le nombre de formats pivot est, de préférence, limité. A titre d'illustration, le module d'intégration peut utiliser un format pivot pour décrire les comptes et un format pivot pour décrire les contrats. Les formats pivot sont décrits, par exemple, à l'aide du langage XML (sigle d'eXtensible Markup Language en terminologie anglo-saxonne). La figure 2 illustre schématiquement un exemple de format générique pouvant être utilisé dans le module d'intégration pour gérer des données relatives aux contrats auxquels peut souscrire un client. La conversion selon le format pivot est une étape intermédiaire de transport des données. Ce format est ici basé sur un modèle de données décrivant un compte de facturation, un client, un contrat, une demande de génération de facture, une demande de consommation sur un compte, une balance d'un compte et une activation d'un service proposé sur un réseau de communication. Afin que le module d'intégration soit indépendant de l'évolution des offres commerciales gérées par les systèmes de facturation et de gestion de la relation client, le format pivot est, de préférence, défini de façon récursive. Comme illustré, la structure du format pivot 200 est hiérarchique, elle comprend ici des références 205 et 210 à une commande et à des paramètres, respectivement. La commande est, par exemple, une commande de création d'un compte de facturation client ou une commande de modification d'un tel compte tandis que les paramètres peuvent notamment comprendre un identifiant client. La structure comprend en outre des références 215 et 220 à une offre principale et aux paramètres associés, respectivement. Une offre principale est, à titre d'illustration, un abonnement de téléphonie mobile, un paramètre associé pouvant être une référence à un forfait. Des offres ou des services annexes peuvent être associés, de façon récursive, à l'offre principale. Ainsi, la structure du format pivot comprend ici une référence 225 à une offre annexe, par exemple un abonnement de téléphonie fixe, une référence 230 à des charges de valorisation à laquelle est associé une référence 235 visant les paramètres relatifs à ces charges et une référence 245 à des services annexes de l'offre principale, par exemple des services de type SMS (sigle de Short Message Service en terminologie anglo-saxonne), à laquelle est associé la référence 250 visant les paramètres relatifs à ces services. La référence 240, liée à la référence 230 des charges de valorisation, a, par exemple, pour objet de déterminer le taux de facturation selon des critères propres au client et à son abonnement. Il convient de remarquer ici que d'autres offres pourraient être associées à l'offre principale ou à une offre ou un service annexe, de façon récursive. La figure 3 représente le transfert d'informations, d'un point de vue fonctionnel, entre une application de gestion de la relation client et une application de facturation, conformément à l'invention. La référence 300 vise ici la partie applicative de gestion de la relation client, la référence 305 vise le module d'intégration et la référence 310 concerne la partie applicative de facturation. Comme illustré, les données traitées selon un format de données 315, propre à l'application de gestion de la relation client, sont converties selon un format générique 320 du module d'intégration. Les données mémorisées selon ce dernier sont alors converties dans un format 330 propre à l'application de facturation. Lors de la conversion des données mémorisées selon le format générique du module d'intégration en données pouvant être traitées par l'application de facturation, des données de celle-ci, mémorisées ici dans la base de données 325, sont utilisées. L'utilisation de données de l'application de facturation pour convertir des données issues de l'application de gestion de la relation client permet d'éviter le codage de règles spécifiques dans le module d'intégration qui est ainsi facilement portable. A titre d'illustration, il peut être considéré ici que les données associées au format de données 315 comprennent en particulier des informations relatives à l'identité d'un client et à un type d'abonnement auquel le client souscrit. Ces données sont transmises au module d'intégration avec une commande de création d'un compte de facturation. A la réception de ces données, le module d'intégration constate, à l'aide d'un moteur d'enrichissement du module d'intégration, qu'il manque des informations par rapport au format générique défini. Il demande donc les informations manquantes à l'application de facturation en suivant les règles définies au sein du moteur d'enrichissement. Ces informations sont, par exemple, celles visant à identifier les services de valorisation permettant la facturation selon la qualité du client et son type d'abonnement. A la réception de celles-ci, elles sont combinées avec les informations reçues de l'application de gestion de la relation client. L'ensemble de ces informations, formatées conformément à l'application de facturation, est alors transmis à cette dernière qui peut alors les traiter directement. La modification de données de l'application de gestion de la relation client, impactant l'application de facturation, est traitée de façon similaire. Cependant, dans ce cas, le module d'intégration exécute une étape supplémentaire de comparaison des données reçues de l'application de gestion de la relation client avec les données connues de l'application de facturation et une étape de consolidation de ces données. La figure 4 illustre un exemple d'algorithme mis en oeuvre dans la couche d'intégration d'applications hétérogènes pour effectuer le transfert de données illustré sur la figure 3. Les références 400, 405 et 410 visent ici la partie applicative de gestion de la relation client, le module d'intégration et la partie applicative de facturation, respectivement. Le module d'intégration est ici appelé par l'application de gestion de la relation client, notée CRM, lorsqu'un compte ou un contrat client est créé ou modifié (étape 415). La fonction d'appel comprend de préférence les données à traiter. Alternativement, à la réception de la commande, le module d'intégration peut adresser une requête à l'application de gestion de la relation client pour obtenir ces données. Lorsqu'elles sont reçues, les données à traiter sont converties selon le format pivot décrit précédemment (étape 420). S'il existe plusieurs formats pivot dans le module d'intégration, il est déterminé selon la nature des données reçues. Selon un mode de réalisation particulièrement simple, cette étape de conversion consiste essentiellement en un réarrangement des données, opération connue sous le nom de mapping en terminologie anglo-saxonne. Un test est alors effectué pour déterminer si l'objet de l'appel est un contrat ou un compte (étape 425). S'il s'agit d'un compte, le contexte est tout d'abord validé (étape 430). Cette étape consiste notamment à comparer les données reçues avec des informations relatives à des modèles de compte mémorisées dans l'application de facturation, par exemple dans la base de données 435. Si le contexte n'est pas valide, par exemple si les informations reçues de l'application de gestion de la relation client ne sont pas compatibles avec les modèles de compte de l'application de facturation, une indication est adressée à l'application de gestion de la relation client et l'opération est annulée. Les données mémorisées dans le format pivot utilisé, ici de type compte, sont alors converties selon le format utilisé par l'application de facturation (étape 440). Cette étape de conversion est également appelée une étape de restructuration des données. Cette étape de restructuration utilise ici des données mémorisées dans l'application de facturation, dans la base de données 435, notamment des informations relatives à des modèles de compte entreprise ou particulier. Pour effectuer cette étape de restructuration, le module d'intégration s'appuie sur son moteur d'enrichissement. A l'issu de l'étape de restructuration, toutes les données nécessaires à l'exécution de l'opération demandée sont ainsi rassemblées. Les données restructurées sont alors transmises à l'application de facturation sous forme d'objet compte (étape 445) pour permettre à cette application de créer ou modifier un compte selon les instructions et les informations contenues dans cet objet (étape 450). Si l'objet de l'appel au module d'intégration est un contrat (étape 425), un second test est effectué pour déterminer s'il s'agit d'une demande de création ou de modification (étape 455). S'il s'agit d'une étape de création, le contexte est tout d'abord validé (étape 460) selon des informations relatives aux modèles de compte de facturation, aux listes de produits/services et aux paramètres associés, issues de l'application de facturation, par exemple de la base de données 465. Cette étape de validation consiste notamment à vérifier que les données reçues de l'application de gestion de la relation client sont conformes aux modèles de compte et aux offres gérées par l'application de facturation. A nouveau, si le contexte n'est pas valide, une indication est adressée à l'application de gestion de la relation client et l'opération est annulée. Les données mémorisées dans le format pivot utilisé, ici de type contrat, sont ensuite restructurées (étape 470). Cette étape de restructuration utilise ici des données mémorisées dans l'application de facturation, dans la base de données 465, notamment des informations relatives aux offres de produits et de services ainsi qu'aux paramètres de valorisation. Ainsi, à l'issu de l'étape de restructuration, toutes les données nécessaires à l'exécution de l'opération demandée sont rassemblées. Les étapes de validation et de restructuration s'appuient sur le moteur d'enrichissement qui associe les types et valeurs des données émises par le CRM à des actions à effectuer. Ces actions vont, entre autres, extraire certaines données de l'application de facturation et permettre la validation des données du CRM ou l'ajout d'informations complétant la demande. Les données restructurées sont alors transmises à l'application de facturation sous forme d'objet contrat (étape 445) pour permettre à cette application de créer un contrat selon les informations contenues dans cet objet (étape 450). Si l'objet de l'appel au module d'intégration est un contrat (étape 425) et s'il s'agit d'une demande de modification (étape 455), le contexte est tout d'abord validé (étape 475) selon des informations relatives aux offres de produits et de services ainsi qu'aux paramètres de valorisation, issues de l'application de facturation, par exemple de la base de données 465. Les données mémorisées dans le format pivot utilisé, ici de type contrat, sont ensuite restructurées (étape 480). Cette étape de restructuration utilise à nouveau des données mémorisées dans l'application de facturation, dans la base de données 465, notamment des informations relatives aux offres de produits et de services ainsi qu'aux paramètres de valorisation. Comme illustré, les étapes 475 et 480 sont répétées plusieurs fois, selon chacune des modifications à effectuer. A nouveau, les étapes de validation et de restructuration s'appuient sur le moteur d'enrichissement. Les données restructurées sont alors transmises à l'application de facturation sous forme d'objet contrat (étape 445) pour permettre à cette application de créer un contrat selon les informations contenues dans cet objet (étape 450). La constitution et la maintenance d'un compte de facturation sont ainsi automatisées. De même, l'association d'un élément de valorisation, qui permet la facturation, contenant par exemple un numéro de téléphone, à un produit souscrit par le client, par exemple une ligne téléphonique mobile, est automatique, tout comme la validation et la constitution des contrats souscrits ou modifiés des clients. De plus, le module d'intégration est suffisamment générique pour s'adopter à la plupart des types d'offres, présents et à venir, notamment les offres combinant la téléphonie fixe et mobile, un accès Internet et la réception de la télévision via le réseau, afin d'être en mesure de gérer les offres du système de facturation qui peuvent évoluer régulièrement. En outre, le module d'intégration ne contient pas d'éléments de configuration spécifiques aux offres, types de contrats ou clients que peut avoir un opérateur. Ainsi, le module d'intégration est capable de s'adapter aux environnements des opérateurs en allant chercher les informations spécifiques dans le système de facturation lui-même, à l'aide de son moteur d'enrichissement s'appuyant sur la structure des formats pivots. Le moteur d'enrichissement comprend une liste de règles de type métier à appliquer lors de la validation et de la restructuration. Alternativement, le moteur d'enrichissement comprend des moyens lui permettant d'accéder à de telles règles. Ces règles sont priorisées afin de permettre, le cas échéant, une exécution séquentielle. Chaque règle du moteur d'enrichissement associe une action à un attribut de la structure récursive du format pivot de la demande. Cet attribut est notamment déterminé par le type de l'élément pointé par cet attribut, par exemple un type commande, service, accès ou paramètre, l'opération demandée sur cet élément, par exemple une création, une modification ou une suppression, la valeur de l'attribut ainsi que le nombre d'itérations dans la structure hiérarchique du format pivot pour l'atteindre. Les actions possibles liées à cet élément pointé sont entre autres une extraction d'information dans une application externe, combinée ou non avec une insertion d'un élément dans la structure de la requête finale, une suppression d'information ou une validation de certaines informations. Chaque règle et chaque action sont, de préférence, associées à une description des éléments à extraire dans l'application externe, par exemple des éléments de valorisation, de cycle de facturation, de compte ou de squelette de paiement par type de client, offre ou service. Ainsi, le moteur de recherche peut déterminer l'élément de l'application externe traité lors d'une validation ou d'une restructuration. Les règles implémentées dans le moteur d'enrichissement permettent notamment d'obtenir ici les éléments suivants, - les éléments permettant de définir quel est le service contenant la charge qui sera valorisée et son type ; - les éléments permettant de connaître les services et les paramètres des services valides au moment de la souscription en consultant les informations historiques des offres et services ; et, - les éléments de type modèle de compte de facturation permettant de définir les attributs de facturation, en particulier la fréquence du cycle de facturation et les informations de délai de paiement, selon le type de client. La figure 5, comprenant les figures 5a et 5b, illustre plus précisément un exemple de mise en oeuvre des fonctions de validation du contexte et de restructuration, illustrées sur la figure 4, exécutées lorsque le module d'intégration reçoit une commande de création d'un contrat. Au début de chaque opération de validation et de restructuration, le moteur d'enrichissement se charge de répertorier, ou d'identifier, toutes les règles de type métiers à appliquer en fonction du type de format pivot et du type d'opération (étape 500). Comme indiqué précédemment, il s'agit, dans l'exemple illustré sur la figure 5, d'une création de contrat. Les règles sont appliquées les unes à la suite des autres selon un ordre prédéterminé. A titre d'illustration, les règles associées au format pivot de type contrat et à l'opération de création peuvent être des règles de validation du compte de facturation, de souscription et de services ainsi que des règles de valorisation. Lorsqu'une règle n'est pas validée, une indication d'erreur est transmise à l'application de gestion de la relation client et l'opération est suspendue. Pour des opérations de validation d'un contexte, le module d'intégration compare les données reçues de l'application de gestion de la relation client avec des informations mémorisées dans l'application de facturation, selon les règles définies dans le moteur d'enrichissement (étape 505). Le module d'intégration construit une requête pour obtenir l'élément renseigné par la règle et transmet une requête à l'application, ici l'application de facturation. Ainsi, lorsque l'application de facturation reçoit une requête visant l'obtention d'informations relatives à un compte de facturation, elle récupère ces informations et les transmets au module d'intégration (étape 510) qui peut alors vérifier le compte de facturation selon les informations reçues de l'application de gestion de la relation client (étape 515). Si la règle appliquée n'est pas une règle de validation (étape 505) ou après validation des paramètres du compte de facturation, les informations relatives aux offres et aux services sont accédées. Ainsi, lorsque l'application de facturation reçoit une requête visant l'obtention d'offres, de services et/ou des paramètres associés, à la date de la souscription d'un contrat, elle extrait ces informations de ses bases de données et les transmet au module d'intégration (étape 520). Des attributs de l'offre mère (215), des offres filles (225) et/ou des services (245), comme par exemple les codes ou dates de souscription, sont utilisés pour extraire les éléments de référence de l'application de facturation. Si la règle appliquée est une règle de validation de service (étape 525), le module d'intégration, via le moteur d'enrichissement, vérifie les données de la souscription reçues de l'application de gestion de la relation client avec les informations reçues précédemment de l'application de facturation (étape 530). Cette étape est, de préférence, réalisée pour chaque souscription, c'est-à-dire pour la souscription principale et toutes les sous- souscriptions qui en dépendent. De façon similaire, si la règle appliquée est une règle de validation de paramètres de service (étape 535), le module d'intégration vérifie les paramètres des services proposés dans la souscription, reçus de l'application de gestion de la relation client, avec les informations reçues précédemment de l'application de facturation (étape 540). Si les informations relatives au compte de facturation sont erronées (étape 515) ou si les données de la souscription (étape 530) et/ou les paramètres de services reçus ne sont pas conformes à l'offre (étape 540), une indication d'erreur est transmise à l'application de gestion de la relation client et l'opération est suspendue (étapes non représentées). Le moteur d'enrichissement contient, de préférence, des règles concernant les charges de valorisation et leurs types. Lorsque la règle appliquée est une règle de valorisation (étape 545), les informations relatives à la charge de valorisation dans l'offre sont alors recherchées dans les données reçues de l'application de facturation (étape 550) et sont associées aux données de souscription reçues de l'application de gestion de la relation client. Une charge de valorisation d'un type donné est identifiée via une règle du moteur d'enrichissement par son attribut et sa valeur dans le format pivot (230). Lorsque la charge de valorisation est identifiée dans l'offre, l'identifiant de valorisation (240) est affecté à cette charge en fonction de son type. Ces informations de valorisation sont alors ajoutées aux données de souscription reçues de l'application de gestion de la relation client (étape 555) pour former l'objet qui permettra à l'application de facturation de créer le contrat correspondant à la souscription. Un test est alors effectué pour déterminer si tous les services correspondant à la souscription en cours de traitement ont été traités (étape 560). Dans la négative, le service suivant est traité (étapes 535 à 555). Si tous les services correspondant à la souscription en cours de traitement ont été traités (étape 560), un autre test est effectué pour déterminer si toutes les souscriptions dépendantes de la souscription principale ont été traitées (étape 565). Dans la négative, la souscription dépendante suivante est traitée (étapes 520 à 560). Enfin, si tous les tous les services correspondant à la souscription en cours de traitement et si toutes les souscriptions dépendantes de la souscription principale ont été traités, un test est effectué pour déterminer si toutes les règles identifiées ont été appliquées. Dans la négative, la règle suivante est appliquée (étapes 505 à 565). Il convient de remarquer que selon le type d'opération, par exemple la modification d'un contrat ou la création de compte, les étapes de vérification et d'insertion d'information peuvent être différentes de celles décrites en référence à la figure 5. De même, l'étape d'insertion peut être remplacée ou comprendre une étape de sélection selon laquelle certaines données reçues de l'application de facturation sont utilisées pour sélectionner d'autres données reçues de l'application de facturation ou des données reçues de l'application de gestion de la relation client, afin de former l'objet devant être transmis à l'application de facturation, et réciproquement. Selon un mode de réalisation particulier, le module d'intégration comprend une interface de type services web, couramment appelés web services, permettant à l'application de gestion de la relation client d'accéder directement aux services proposés par ce module. L'accès à ces services peut être conforme au standard http/SOAP (sigle d'HyperText Transfer Protocol et de Simple Object Access Protocol en terminologie anglo-saxonne). A titre d'illustration, les services proposés peuvent être les suivants, - envoi d'une opération de création ou modification des données client sur un format pivot � Client � ; - envoi d'une opération de création ou modification des données compte de facturation sur un format pivot � Compte � ; - envoi d'une opération de création ou modification des données 15 contrat sur un format pivot � Commande � ; - envoi d'une opération de demande de devis sur un format pivot � Commande � ; - envoi d'une opération d'activation sur le réseau des services souscrits sur un format pivot � Activation � ; 20 - envoi d'une opération de demande de génération de facture sur un format pivot � Facture � ; et, - envoi d'une opération de demande de balance sur le compte de facturation sur un format pivot � Balance �. Selon un schéma classique de gestion des services, les requêtes 25 reçues de l'application de gestion de la relation client sont mémorisées dans une file d'attente et traitées selon leur ordre d'arrivée. Alternativement, les requêtes peuvent être traitées de façon synchrone. Toujours selon un mode de réalisation particulier, l'application de facturation est accessible via un API (sigle d'Application Programming Interface 30 en terminologie anglo-saxonne) spécifique. Pour améliorer la disponibilité du module d'intégration, celui-ci peut être doublé, de façon purement logicielle ou de façon logicielle et matérielle, selon un mécanisme de redondance. Ainsi, si le module d'intégration connaît une défaillance, le module redondant peut prendre le relais. La file d'attente des requêtes est avantageusement recopiée du module défaillant vers le module redondant. La défaillance n'est détectable par l'application de gestion de la relation client que s'il y a au moins une requête en cours de traitement dans le module d'intégration. Dans ce cas, l'application détectera une erreur et pourra soumettre à nouveau la requête. La figure 6 illustre un exemple d'architecture matérielle adaptée à mettre en oeuvre l'invention, notamment les algorithmes représentés sur les figures 4 et 5. Le dispositif 600 comporte ici un bus de communication 605 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 610 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 615 (ROM, acronyme de Read Only Memory 15 en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 620 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 20 cours de l'exécution des programmes précités ; et - une interface de communication 650 adaptée à transmettre et à recevoir des données, notamment vers et depuis des dispositifs sur lesquels sont exécutés les applications hétérogènes. Le dispositif 600 dispose également, de préférence, des éléments 25 suivants : - un écran 625 permettant de visualiser des données et pouvant servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 630 ou d'un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; 30 - d'un disque dur 635 pouvant comporter les programmes précités et des données traitées ou à traiter selon l'invention ; et - d'un lecteur de cartes mémoires 640 adapté à recevoir une carte mémoire 645 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 600 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 600 directement ou par l'intermédiaire d'un autre élément du dispositif 600. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 635 ou en mémoire morte 615. Selon une variante, la carte mémoire 645 peut contenir des données, notamment une table de correspondance entre les événements détectés et les commandes pouvant être sollicitées, ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 600, est stocké dans le disque dur 635. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 650, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 600 avant d'être exécutés. L'unité centrale 610 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 635 ou dans la mémoire morte 615 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 635 ou la mémoire morte 615, sont transférés dans la mémoire vive 620 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications 5 dans la description précédente. REVENDICATIONS1. Procédé d'ordinateur pour l'intégration d'applications hétérogènes dans un système comprenant au moins deux applications hétérogènes, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception d'au moins une première donnée d'une desdites au moins deux applications hétérogènes selon un format spécifique à ladite une 10 desdites au moins deux applications hétérogènes ; - conversion (420) de la dite au moins une donnée reçue selon un format de donnée prédéterminé distinct des formats de données utilisés par lesdites au moins deux applications hétérogènes ; - réception d'au moins une seconde donnée de l'autre desdites au 15 moins deux applications hétérogènes ; - création (440, 470, 480) d'un objet comprenant ladite au moins une première donnée reçue convertie dans ledit format de donnée prédéterminé, ladite création étant réalisée selon ladite au moins une seconde donnée reçue, ledit objet pouvant être traité directement par ladite autre 20 desdites au moins deux applications hétérogènes ; et, - transmission (445) dudit objet créé à ladite autre desdites au moins deux applications hétérogènes. 2. Procédé selon la revendication 1 comprenant en outre une étape de vérification (430, 460, 475) d'un contexte basé sur la comparaison de ladite 25 au moins une première donnée reçue avec au moins une autre donnée reçue de ladite autre desdites au moins deux applications hétérogènes, distincte de ladite au moins une seconde donnée. 3. Procédé selon la revendication 1 ou la revendication 2 caractérisé en ce que ledit format prédéterminé à une structure récursive. 30 4. Procédé selon la revendication 3 selon lequel ladite étape de création comprend au moins une itération liée à la récursivité dudit formatprédéterminé utilisé pour la conversion de ladite au moins une première donnée. 5. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite étape de création dudit objet comprenant ladite au moins une première donnée reçue convertie dans ledit format de donnée prédéterminé, ladite création étant réalisée selon ladite au moins une seconde donnée reçue, comprend une étape d'insertion de ladite au moins une seconde donnée dans ledit objet. 6. Procédé selon l'une quelconque des revendications précédentes 10 selon lequel le procédé est accessible à ladite une desdites au moins deux applications hétérogènes sous forme de services web. 7. Procédé selon l'une quelconque des revendications précédentes selon lequel ledit procédé accède à ladite autre desdites au moins deux applications hétérogènes par une interface spécifique de ladite autre desdites 15 au moins deux applications hétérogènes. 8. Procédé selon l'une quelconque des revendications précédentes selon lequel ladite une desdites au moins deux applications hétérogènes est une application de gestion de la relation client, l'autre desdites au moins deux applications hétérogènes étant une application de facturation et/ou d'activation 20 de services. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes lorsque ledit programme est exécuté sur un ordinateur. 25 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.