Brevet FR2878351A1 — publié le 20060526

Le secteur technique de la présente invention est celui des systèmes d'ingénierie logistique. Il est connu dans ce domaine, des systèmes logistiques qui gèrent un produit durant une phase particulière du cycle de vie, principalement la phase d'utilisation. Ainsi des systèmes permettent de traiter les lots de rechange ou de prédire les potentiels d'utilisation disponibles pour un produit. La difficulté de tous les systèmes existant est de pouvoir accéder aux informations sur un produit issues de l'ingénierie système tout en garantissant la fiabilité et la pérennité de ces informations. La présente invention répond à ces différents problèmes, et à bien d'autres, en s'interfaçant avec les métiers de l'analyse système et avec tous les contributeurs d'un projet dès les phases les plus précoces du cycle de vie. Cette interface reste forte et garantit la mise à jour en temps réel des informations afférentes au produit. L'invention a pour objet un système d'ingénierie logistique simultanée multi produit destiné à gérer et suivre au moins un produit durant son cycle de vie, en facilitant la collaboration de différents contributeurs, ledit produit se décomposant de manière arborescente en articles, ledit cycle de vie comportant plusieurs phases successives et ledit système comprenant un référentiel de données unifié stockant, au fur et à mesure de leur disponibilité et/ou modification, toutes les données techniques, calendaires et financières afférentes au produit, durant chacune des phases de son cycle de vie, en les attachant aux articles concernés, afin de construire et de gérer le maintien en condition opérationnelle dudit produit. Selon une autre caractéristique de l'invention, le système d'ingénierie logistique comprend, intégré en son sein ou interfacé au moyen d'interfaces bidirectionnelles, tous les outils de transformation ( process ) permettant de créer ou de modifier des données techniques, calendaires ou financières afférentes au produit au sein du référentiel de données. Selon une autre caractéristique de l'invention, les outils de transformation sont codés en langage XML ou en langage JAVA. Selon une autre caractéristique de l'invention, toutes 5 les données stockées dans le référentiel sont historisées en version et gérées en configuration. Selon une autre caractéristique de l'invention, le système d'ingénierie logistique comporte des moyens pour capturer un contexte et toute donnée est associée à son contexte. Selon une autre caractéristique de l'invention, l'implémentation du système est construite sur un environnement orienté objet. Selon une autre caractéristique de l'invention, les 15 objets du système sont implémentés en utilisant les langages JAVA et J2EE. Selon une autre caractéristique de l'invention, un produit comprend des articles, des fonctions et des relations entre ces articles et ces fonctions. Selon une autre caractéristique de l'invention, une relation définit un lien fort ou un lien faible entre un organe et une fonction. Selon une autre caractéristique de l'invention, les données du référentiel sont consultables en temps réel par 25 les différents contributeurs. Selon une autre caractéristique de l'invention, les contributeurs comprennent: le responsable marketing ou commercial, le responsable de la définition, l'acheteur, le responsable de la production, le responsable du soutien logistique, l'utilisateur du produit, le client ainsi que toute personne intervenant sur le produit durant son cycle de vie. Selon une autre caractéristique de l'invention, le système d'ingénierie logistique comporte des rôles, associés aux différents contributeurs, définissant des prérogatives d'accès, des droits et des devoirs. Selon une autre caractéristique de l'invention, une donnée du référentiel de données est modifiable par un rôle et un seul, en fonction du type de la donnée et de la phase du cycle de vie auquel elle se rattache. Selon une autre caractéristique de l'invention, le système d'ingénierie logistique comporte et gère des demandes de travail permettant de planifier une tâche et/ou de réaliser une collaboration entre rôles. Selon une autre caractéristique de l'invention, le système d'ingénierie logistique respecte et utilise le standard de codage, d'échange et de partage des données industrielles ISO 10303 et le standard d'ingéniérie système/ cycle de vie ISO 15288. Un avantage du système selon l'invention est d'offrir un outil unifié de gestion des produits tout au long du cycle de vie de ces produits. Un autre avantage du système selon l'invention est d'intégrer tous les processus et activités intervenant tout au long du cycle de vie du produit. Un autre avantage du système permettre une collaboration 20 contributeurs à un produit. Un autre avantage du systèmeselon l'invention est de entre les différents selon l'invention est de permettre un accès en temps réel pour tous les contributeurs, à toutes les informations afférentes à un produit. Un autre avantage du système selon l'invention est d'offrir une traçabilité tant montante que descendante pour un article ou un produit donné. Un autre avantage du système selon l'invention est de permettre une centralisation de toutes les informations 30 pertinentes relatives à un produit. Un autre avantage du système selon l'invention est de pérenniser les informations concernant un produit, de les stocker dans les premières phases du cycle de vie et de pouvoir garantir leur disponibilité jusqu'aux phases ultimes dans vingt, trente ou cinquante ans. Un autre avantage du système selon l'invention est d'obliger les différents contributeurs à réaliser les activités, et notamment les activités logistiques au moment où elles sont les plus efficaces. Un autre avantage du système selon l'invention est de permettre d'obtenir une réduction substantielle des coûts de possession et une augmentation de la disponibilité opérationnelle des produits. Un tel système est applicable à toutes les industries, civiles et/ou militaires, qui recherchent une réduction des coûts et une amélioration continue au cours du cycle de vie des performances des produits (électronique, avionique, automobile, systèmes d'armes, maritime, transport,...). Enfin, ce système permet une économie allant de 10 à 20% sur le temps d'ingéniérie logistique. D'autres caractéristiques, détails et avantages de l'invention ressortiront plus clairement de la description détaillée donnée ci-après à titre indicatif en relation avec des dessins sur lesquels: - la figure 1 montre une vue d'ensemble du système selon l'invention, - la figure 2 détaille la structure de données d'un 20 produit au sein du référentiel de données. Sur la figure 1, est représentée une vue schématique d'un système 1 d'ingénierie logistique simultanée selon l'invention. Par simultanée, on entend un système permettant un travail commun ou ensemble de différents partenaires. Ce système est capable de gérer plusieurs produits 2 dont la structure est détaillée ci-dessous. Le système 1 permet de suivre un produit 2 tout au long de son cycle de vie. Le cycle de vie comprend toutes les étapes de vie d'un produit 2 industriel depuis la spécification des besoins jusqu'au retrait du service. Il est possible arbitrairement de diviser cette vie en étapes majeures que sont la spécification ou l'expression et l'analyse des besoins, la conception, la réalisation/fabrication, l'utilisation ou la phase de service et enfin la réforme ou la phase de retrait du service. Au cours de ce cycle de vie de nombreuses données 5 afférentes au produit 2 vont être créées puis le cas échéant modifiées ou mise à jour pour refléter l'évolution du produit 2. Le système 1 durant TOUT ce cycle de vie va stocker TOUTES les informations utiles à la gestion de ce produit 2 mais aussi mieux concevoir, développer et maintenir les produits futurs. Ces données 5 sont nombreuses et de types très variés. On peut globalement classer ces données en données techniques, calendaires ou financières. Les données techniques, comprennent, entre autres, la géométrie d'un article modélisée par un modèle tridimensionnel de type CAO, la matière, le poids ou encore la fiabilité, mais aussi la disponibilité, le ou les services ou sous-traitants capables de fabriquer ledit article 3a ou encore le nombre d'exemplaire en stock ou le délai de fabrication, ou de réapprovisionnement. Les données techniques comprennent encore tous les documents afférents à l'article: rapports d'études, dossier de définition, de fabrication, de sûreté de fonctionnement, les normes et règlements applicables audit article. Les données calendaires comprennent, entre autres, la date de définition, la date de fabrication, la date de mise en service, ou encore la date de la dernière défaillance d'un article 3a donné. Les données calendaires contiennent aussi toutes les informations concernant la gestion des versions. Les données financières comprennent par exemple le coût, le prix de l'article ou encore les formules d'indexation. Ces listes ne sont bien entendu qu'illustratives et le référentiel de données 4 a vocation à accueillir TOUTE donnée 5, quelle que soit sa nature, quelle que soit sa forme: numérique, textuelle ou graphique, afférente au produit 2. La figure 2 zoome sur le produit 2 de la figure 1 et illustre l'organisation au sein du référentiel de données 4 des informations concernant ledit produit 2. Le produit 2 comprend différents articles 3a à 3f organisés classiquement selon la structure arborescente de décomposition organique du produit 2. A chaque article 3a-3f est associé une structure de données 5 permettant le stockage des données et informations afférentes à cet article. La description du produit 2 est avantageusement complétée par l'introduction spécifique de fonctions 10a à 10c. Ainsi il est possible d'aborder un problème particulier soit par l'aspect organique au travers des articles 3a-3f soit par l'aspect fonctionnel au travers des fonctions 10a-10c. Les fonctions l0a-10c sont avantageusement associées avec les articles 3a-3f au moyen de liens lla à lld. Par commodité on distingue des liens forts et des liens faibles . Un lien faible signifie que l'article participe à la réalisation de la fonction à laquelle il est lié. Un lien fort signifie que l'article réalise la fonction. Sur la figure 2 les liens forts sont représentés en trait plein, alors que les liens faibles sont figurés en trait tireté. Ainsi le lien fort lla indique que l'article 3d réalise la fonction 10c. Le lien faible 11c indique quand à lui que l'article 3a participe à la réalisation de la fonction 10a. Une structure de données 5 est associée à chaque article 3a et à chaque fonction 10a. Dans cette structure de données 5 sont stockées toutes les données afférentes au produit 2 et plus particulièrement associées audit article 3a ou à ladite fonction 10a. On est ainsi sûr de retrouver rapidement toute donnée utile en partant soit de l'article 3a concerné, soit de la fonction 10a concernée. L'arborescence des articles et/ou les différents liens 10a reliant les articles 3a et les fonctions 10a permettent de faire le lien entre ces derniers. Une traçabilité peut ainsi être construite tant dans le sens montant que dans le sens descendant. Ainsi par exemple, lors de l'apparition d'un problème de freinage sur un véhicule donné. Le numéro de série du véhicule permet de déterminer quel frein (type, modèle, définition) est installé. Il est possible d'accéder à l'élément soit par l'article frein soit par la fonction freinage. La traçabilité montante va permettre de déterminer l'historique de cet article. Ainsi est connu le lot de fabrication auquel appartient l'article, mais aussi quelle définition et même quelle spécification ont été utilisées pour ce frein. Il est ainsi possible, le cas échéant, de prendre toute mesure corrective utile, au niveau juste nécessaire. Si le problème est lié à un défaut de fabrication, l'article est changé. S'il s'avère qu'un défaut de conception est présent, il est possible de lancer une intervention visant à reprendre une étude au niveau de la conception dudit article. La traçabilité descendante va permettre de retrouver tous les articles ou fonctions potentiellement sujets au même problème. Ainsi dans le cas où un problème de définition est identifié, il est possible de descendre jusqu'à identifier tous les articles freins produits selon cette définition. Il est ensuite possible de les localiser: quel véhicule, chez quel client, ou dans quel lot de rechange. Le système est ici avantageusement multi-produit et si ce même frein a été réutilisé pour un autre type de matériel il sera identifié et localisé aussi. Ainsi le système permet de suivre en montant ou en descendant à partir d'un fait technique tous les autres éléments pouvant être mis en cause ou impacté par ledit fait technique. Ces liens de traçabilité s'étendent même au- delà d'un produit et peuvent avoir des conséquences sur d'autres produits pour peu qu'ils partagent des articles, des documents ou des normes avec le produit concerné par le fait technique déclenchant. Toutes les données concernant les différents produits 2 sont stockées dans un référentiel de données 4 unique. L'une des caractéristiques essentielles de l'invention est de centraliser toutes les données 5 afférentes à un produit 2 donné dans un unique référentiel de données 4 qui contient à un instant donné toutes les informations 5 techniques, calendaires et financières nécessaires à tout contributeur 12 ayant à intervenir d'une manière ou d'une autre sur ledit produit 2. Pour ce faire le système 1 s'interface obligatoirement avec toutes les personnes ou entités intervenant, modifiant ou utilisant ledit produit 2 et que l'on nomme de manière générique les contributeurs 12. La définition de contributeur 12 est large. Sont inclus dans les contributeurs le vendeur du produit, le concepteur, le réalisateur, le responsable de maintenance, mais aussi le prescripteur, le client ou encore l'utilisateur. Est contributeur 12 toute personne, entité ou service, interagissant avec le produit 2 durant l'une quelconque des phases de son cycle de vie. Pour garantir l'unicité du référentiel de données 4, le système est un passage obligé pour tous les contributeurs 12 lors de leurs accès aux données 5 que ce soit pour les consulter, pour les créer ou pour les modifier en cas d'évolution, de transformation ou de mise à jour de ces données 5. Pour cela le système 1 fournit tous les outils 6 de consultation et/ou de modification de toutes les données 5 techniques, calendaires ou financières. Ceci est réalisé selon deux modalités selon le type et la forme des données 5. Pour les données 5 les plus simples un moyen spécifique de consultation et le cas échéant de modification, sous la forme d'un programme spécifique est intégré au système 1. Ainsi par exemple la fiabilité d'un produit 2, connue à l'issue d'une étude de fiabilité peut être renseignée dans le référentiel de données 4, attaché audit produit 2 par un simple éditeur ou un outil de type outil d'accès à une base de données interfaçant le référentiel de données 4. La seconde forme de réalisation d'un outil de modification 6 correspondant soit à des données plus complexes ou le cas échéant à un outil déjà existant, est l'interfaçage avec ledit outil préexistant au moyen d'interfaces bidirectionnelles d'échanges de données. Ainsi par exemple dans le cas de la géométrie tridimensionnelle d'un produit 2 ou d'un article 3a, cette géométrie est connue par un modèle tridimensionnel. Ce modèle tridimensionnel complexe est crée et modifié par un outil de CAO (Conception assistée par Ordinateur) dédié. Cet outil de CAO est conservé pour procéder aux modifications de la géométrie de l'article 3a. Par contre le système 1 met en oeuvre une interface bidirectionnelle permettant d'une part de transformer le modèle tridimensionnel de l'article dans un format stockable dans le référentiel de données 4 attaché à cet article 3a et d'autre part de transformer de manière inverse le modèle géométrique de l'article stocké dans le référentiel de données 4 en un modèle géométrique exploitable par l'outil de CAC). Ceci s'effectue de manière transparente depuis le système 1, par exemple par un lancement direct de l'outil CAO, par le système 1 depuis son interface unique d'utilisation. A l'issue de la session de modification des données CAO, le système 1 reprend la main après avoir converti, au moyen de l'interface bidirectionnelle, les données géométriques du modèle CAO dans le format de stockage compatible du référentiel de données 4, en format ISO 10303. Pour permettre une simple consultation du modèle géométrique, un module spécifique de visualisation est réalisé, interne au système 1, capable de représenter le modèle tridimensionnel directement à partir de la représentation stockée dans le référentiel de données 4. Une autre caractéristique essentielle de l'invention est que tout accès et surtout toute modification d'une donnée 5 quelconque afférente à un produit 2 s'effectue par l'intermédiaire du système 1. Pour cela le système 1 comprend tous les outils de transformation 6 permettant de créer ou de modifier des données 5. Ces outils de transformation 6 sont intégrés au système 1 directement en son sein ou interfacés de manière bidirectionnelle avec des outils extérieurs. Il est important que les données 5 soient mises à jour le plus tôt possible dès qu'elles existent ou dès qu'elles sont modifiées. Pour cela le système 1 offre tous les outils de consultation et de modification 6 nécessaires à la consultation et à la mise à jour de toutes ces données 5. Il est ainsi possible d'avoir un référentiel de données 4 à jour et cohérent avec l'état réel des articles 3a et produits 2 qu'il gère. En retour les différents contributeurs 12 qui consultent en direct et en temps réel accèdent à des données qui sont en permanence pertinentes et qui le restent en temps réel. Ainsi un responsable de maintenance qui consulte la définition d'un article frein sérialisé donné peut connaître la définition précise du frein concerné mais aussi apprendre que la définition a fait l'objet d'une évolution pour des lots de fabrication ultérieurs en raison d'un problème technique identifié entre temps. Il peut aussi savoir si la nouvelle définition reste compatible de sa configuration propre. Afin de pouvoir développer simplement et garantir une certaine pérennité des outils de transformation 6 (ou des interfaces bidirectionnelles qui en tiennent lieu), ces outils de transformation 6 sont avantageusement codés en utilisant des langages parmi les plus utilisés dans l'industrie. Ont été préférentiellement retenu les langages bien connus de l'homme du métier que sont XML et JAVA. Durant le cycle de vie d'un produit qui peut s'étendre sur une durée pouvant atteindre 50 ans pour certaines industries, les informations afférentes à un produit peuvent évoluer. Il est important de conserver une trace de ces évolutions afin par exemple de connaître l'état exact d'un matériel à une époque donnée. Pour cela, pour toute donnée 5 stockée dans le référentiel de données 4, sont conservées toutes les versions de cette donnée avec pour chaque version les dates de début et de fin de validité. Cette donnée 5 est ainsi historisée. Il est possible de connaître son état particulier à une date donnée. Il en est de même de tous les liens. Ainsi il est possible de retrouver pour une date donnée, l'état particulier d'une donnée 5 et ses liens avec les autres données 5. Ceci enrichit les recherches de traçabilité qui peuvent ainsi être réalisée dans l'espace et dans le temps. De manière similaire toute donnée 5 qui participe d'une configuration est sauvegardée dans son contexte. Ainsi si un sous-ensemble se décompose en une configuration particulière, cette configuration (composition, topologie) est archivée avec ses dates de validité. Lorsque cette configuration évolue, la nouvelle configuration est stockée avec ses propres dates. Tout est ainsi enregistré et permet à tout moment de revenir à une date antérieure et de se replacer dans la configuration et/ou la version de l'époque. La plupart du temps, une information n'est exploitable que dans son contexte. A titre d'exemple, un rapport d'incident concernant un article, un équipement ou une fonction n'est exploitable que si est connu l'article en cause, la date, les conditions d'utilisation, l'historique d'emploi, le type de mission et d'autres informations contextuelles de ce type. Une caractéristique importante de l'invention est que le système propose des moyens de capturer le contexte d'une information. Ainsi, le rapport d'incident de l'exemple précédent lorsqu'il est renseigné par un contributeur 12 dans le référentiel de données 4 du système 1 est nécessairement accompagné de son contexte (localisation géographique, type de mission, phase de mission, climat, température, responsable de maintenance, etc). Pour cela, le système 1 connaît, par exemple par des liens entre les objets, les éléments d'informations que doit contenir le contexte pour une information de type rapport d'incident. Lors du renseignement de ce rapport d'incident, le système déclenche une application spécifique qui pré-renseigne le contexte de ce rapport de l'incident et attend la validation de l'information par l'utilisateur. Ce contexte comprend des éléments que le système 1 peut trouver lui-même dans le référentiel de données 4 ou qu'il obtient, par exemple en questionnant le contributeur 12. L'application spécifique réunit tous les éléments du contexte et les transmet au système 1 pour un stockage dans le référentiel de données, associé au stockage de l'incident. Ainsi l'incident est stocké dans le système 1 associé avec son contexte, ce qui lui confère toute la pertinence nécessaire à son exploitation. Avantageusement le système 1 et toutes les données 5 et tous les outils qu'il contient: données article, données fonction, données lien, arborescences,... outils de gestion et d'accès au référentiel de données 4, outils de transformation 6 ou interfaces bidirectionnelles avec des outils de transformation externes, application de présentation ou d'interface spécifique,... sont codées en utilisant un environnement orienté objet. Un tel environnement, connu de l'homme du métier, offre une capacité de typage des objets du monde, une facilité de modélisation tant des objets du monde que des relations et opérations qui les animent. Un tel environnement offre de plus une clarté de modélisation des objets et opérations possibles et favorise la pérennité du système 1 dans le futur. Plus particulièrement, l'environnement orienté objet utilisé est un des standards de l'industrie. Le langage retenu est avantageusement le langage JAVA ou son extension la technologie J2EE. L'utilisation de tels standards favorise encore la pérennité du système en garantissant la disponibilité de tels environnements dans le futur et en favorisant d'éventuels portages le cas échéant nécessaires. Ces langages sont particulièrement adaptés tant à la description des objets que sont les données 5 afférentes aux fonctions 10a ou aux articles 3a que les processus / outils de transformation 6 de ces données 5. La figure 2 décrit particulièrement la structure de données associée à un produit 2. Un produit comprend des articles 3a-3f. Ces articles 3a-3f sont organisés selon des relations de filiation permettant de modéliser l'arborescence organique du produit 2. La description est avantageusement complétée par des fonctions 10a qui complètent la vision du produit 2 selon l'angle fonctionnel. Des relations/liens lia permettent de modéliser au sein du système 1 les associations entre les articles organiques 3a et les fonctions 10a. Le système 1 gère simultanément de nombreux articles et fonctions et peut gérer plusieurs produits. L'intérêt d'une entreprise est d'intégrer dans le système 1 la totalité de ses productions afin de produire le plus de synergies possibles entre les différents produits 2. Entre les articles 3a et les fonctions 10a sont avantageusement mis en place deux types de lien relationnel lla. Sont utilisés des liens faibles et des liens forts. Un lien fort lla est défini entre un article 3d et une fonction 10c lorsque ledit article 3d réalise ladite fonction 10c. Un lien faible lib est défini entre un article 3c et une fonction 10c lorsque ledit article participe à la réalisation de ladite fonction 10c. Les données 5 contenues dans le référentiel de données 4 sont modifiables en fonction de leur évolution ou mise à jour. Ainsi une donnée 5 est consultable dans sa dernière mise à jour. Elle est aussi consultable, de par son historisation, dans toutes les versions précédentes. Le référentiel de donnée 4 est ainsi mis à jour en permanence et permet de connaître et de consulter la dernière mise à jour d'une information ou données 5. Pour être véritablement utile et constituer un outil collaboratif entre les différents contributeurs 12 le système 1 assure une mise à jour et une consultation des données 5 en temps réel. Le système 1 selon l'invention basé sur des environnements objets est constitué de modules séparés pouvant être distribués sur un réseau. La répartition des différents constituants du système peut être très libre et chaque constituant peut être distribué afin d'être placé au plus près de son ou ses utilisateurs privilégiés. Le système 1 est construit comme une application client serveur de type web. Ainsi, tout contributeur 12 accède à l'application au moyen d'un navigateur installé chez le client. Le langage HTML est avantageusement utilisé pour définir toute requête de consultation ou de modification du référentiel de données 4 envoyée au système 1. Selon son besoin, par exemple simple consultation des données 5 ou modification lourde d'une information technique complexe, un contributeur accède au système 1 via une interface client riche ou client léger. Ainsi une simple consultation d'une date de disponibilité d'un article peut s'effectuer au moyen d'une interface client léger, par exemple sur un ordinateur de poche de type assistant personnel (PDA). A contrario la visualisation de la définition géométrique d'un article 3a, qui nécessite la mise en oeuvre d'une machine plus performante, s'effectue au moyen d'une interface client riche depuis un ordinateur personnel. Les différents contributeurs 12 travaillent simultanément autour d'un produit 2 et le font évoluer ensemble. Dans le cadre d'utilisation du système 1, les contributeurs 12 comprennent l'équipe projet étendue. Les contributeurs comprennent toutes les personnes ou équipes intervenant autour du produit 2 et ceci tout au long des étapes du cycle de vie. Sont inclus dans les contributeurs celui qui définit les premiers concepts produit: le responsable marketing, celui qui vend le produit: le responsable commercial, celui qui conçoit le produit: le responsable étude, celui qui le définit: le responsable de la définition, mais aussi ceux qui contribue à sa réalisation: l'acheteur, le responsable de la production, et aussi la logistique: le responsable du soutien logistique. Tous ceux qui de près ou de loin interviennent dans la vie du produit 2 sont considérés comme contributeurs 12 et à ce titre s'interfacent avec le système 1 pour le consulter ou pour apporter leur contribution en faisant évoluer les données 5. La nouveauté de l'approche mise en oeuvre avec lesystème 1 selon l'invention est l'adjonction aux contributeurs internes des autres contributeurs que sont l'utilisateur du produit, le client ou encore le prescripteur. Ainsi toute personne ou entité qui intervient autour du produit 2, avant, pendant et après son utilisation est concerné par le système 1 et est contributeur 12. Afin de bien clarifier les prérogatives de chaque contributeur 12, en terme de droit et de devoirs, le système définit pour chaque contributeur 12 un rôle 13a- 13d. Un rôle 13a assure l'interface entre le système 1 et le contributeur 12 concerné. Un rôle 13a détermine et contrôle ce que peut faire ou ne pas faire un contributeur 12 donné. Un rôle 13a correspond à une fonction. Une même personne physique peut être responsable et assumer plusieurs fonctions. Dans ce cas elle est contributeur 12 à plusieurs titres et utilise une interface rôle 13a-13d pour chacune de ses fonctions contributrices. Un rôle détermine quelles données 5 un contributeur 12 peut consulter, toutes les données n'étant pas forcément accessibles à tous. Ainsi sont définies pour chaque rôle quelles données lui sont utiles et nécessaires dans la réalisation de ses tâches propres. De même un rôle 13a détermine quelles données 5 un contributeur 12 peut créer ou modifier. De plus un rôle 13a détermine, planifie et contrôle l'exécution des tâches que doit réaliser un contributeur 12. Ainsi un rôle 12 a charge de prévenir un contributeur 12 qu'une tâche lui est assignée. Dès que les données d'entrée de la tâche prescrite, généralement produites par un autre contributeur, sont disponibles, le contributeur 12, dont le rôle 13a définit qu'il est en charge de la réalisation de la tâche prescrite, est prévenu par le système 1 qu'il doit réaliser sa tâche. Le système assure ensuite un suivi de l'exécution de ladite tâche jusqu'à sa complétion. Ainsi les rôles 13a, attachés à des fonctions de l'entreprise, telles que concepteur, définisseur, producteur, analyste logistique, utilisateur_ définissent l'ensemble des méthodes de fonctionnement et sont codées en fonction de l'organisation de l'entreprise et des missions effectives de chaque contributeur 12. Afin de garantir la cohérence du référentiel de données 4, une donnée 5 ne peut être modifiée que par un rôle 13a et un seul. L'ensemble des données 5 est ainsi partagé entre tous les contributeurs 12. Plusieurs contributeurs peuvent disposer d'un accès en consultation sur une même donnée 5, mais un seul contributeur 12, au moyen de son rôle 13a, peut la créer ou la modifier. Il peut arriver que plusieurs contributeurs 12 participent à la détermination d'une donnée 5. Un seul contributeur 12 est déterminé pour être responsable, à un instant donné, de cette donnée 5 et peut la modifier. Les autres contributeurs qui veulent modifier une donnée devront le faire via le responsable après négociation avec ce dernier. La responsabilité d'une donnée 5 peut passer d'un rôle 13a à un autre au cours du cycle de vie. Ainsi par exemple une dimension fonctionnelle d'un article peut être sous la responsabilité du rôle définisseur en phase de définition et être ensuite transférée sous la responsabilité du rôle logisticien en phase d'utilisation du produit 2. En tout état de cause, une donnée 5 est à un instant donné, sous la responsabilité d'un rôle 13a et d'un seul. Afin de gérer la planification et le suivi de réalisation des différentes tâches des différents rôles 13a nécessaires à la production des différentes données nécessaires à la vie du produit 2, le système 1 comprend et gère le suivi des travaux ou workflow à savoir la demande, la planification, le lancement, l'exécution, la clôture. Ces demandes de travail déterminent tous les éléments nécessaires à la réalisation d'une tâche donnée. Ainsi, une demande de travail comporte les données nécessaires en entrée de la tâche, les ressources nécessaires (matériel, personnel, expertise, etc) ainsi que les données attendues en sortie. Dès que les données d'entrée sont disponibles, le module workflow prévient le contributeur qui doit réaliser la tâche et lui en assigne la réalisation. L'activité workflow est close lorsque le contributeur répond en fournissant les données de sorties attendues. Les demandes de travail peuvent être automatiquement crées à partir des tâches définies dans les rôles 13a des différents contributeurs 12. Un workflow peut aussi être crée à l'initiative d'un contributeur 12 pour répondre à un besoin ponctuel. Ainsi un contributeur 12 souhaitant faire modifier une donnée 5 (par exemple une demande de changement de version d'une définition) dont il n'est pas responsable et pour laquelle il n'a en conséquence pas accès en modification, peut initier une demande de modification. Cette demande est destinée au contributeur responsable de la donnée 5 concernée et ce contributeur est assigné à y répondre. La gestion de ces demandes de travail assurées par le système 1, permet la planification et le suivi de toutes les tâches nécessaires à la vie du produit 2. La création possible par tout contributeur 12 d'une demande à volonté permet de définir, de formaliser et aussi d'historiser les échanges, et permet la collaboration entre les différents contributeurs 12 et rôles 13a. On sait que les produits gérés par le système 1 objet de l'invention ont une durée de vie pouvant atteindre ou dépasser 20, 30 ou même 50 ans. Il est important que le système 1 mis en place aujourd'hui puisse encore fonctionner et au moins permettre l'accès aux données 5 du référentiel 4 durant toute la vie d'un produit 2. Pour favoriser la pérennité de l'outil, comme vu précédemment, ce dernier est codé selon des méthodologies très diffusées et portables: environnement objet, langages HTML, XML, JAVA, J2EE,... Afin de favoriser la pérennité des données elles-mêmes, qu'il importe de pouvoir conserver, à défaut de l'outil luimême, ces dernières sont codées selon les préconisations d'un standard de codage, d'échange et de partage des données industrielles: le standard normatif ISO 10303. Ce standard définit la forme de toute donnée 5 du type de celles stockées par le système 1 dans le référentiel de données 4. Ceci favorise la pérennité de ce référentiel en ce que d'autres outils permettront d'accéder au référentiel 4, et que les outils périphériques, par exemple les environnements de gestion de production ou les systèmes CAO du futur, qui pour la plupart seront conformes aux recommandations de cette norme ISO 10303, offriront des interfaces bidirectionnelles compatibles des formats retenus pour les données du référentiel 4. Le système selon l'invention assure la gestion de configuration de tout type d'objets y compris l'information dite non-structurée comme la documentation durant chacune des phases de cycle de vie. Par ce biais, il permet de dématérialiser tout type de documentation relative au produit y compris les cartes de travail, les gammes de montage et de démontage afin de fournir une version à jour de ces éléments aux contributeurs en particulier ceux qui se trouvent sur le terrain. REVENDICATIONS 1. Système d'ingénierie logistique simultanée multi produit destiné à gérer et suivre au moins un produit durant son cycle de vie, en facilitant la collaboration de différents contributeurs, ledit produit se décomposant de manière arborescente en articles, ledit cycle de vie comportant plusieurs phases successives et ledit système comprenant un référentiel de données, caractérisé en ce que le référentiel (4) de données comporte un moyen central de mémorisation destiné à stocker, au fur et à mesure de leur disponibilité et/ou modification, toutes les données techniques, calendaires et financières afférentes au produit, durant chacune des phases de son cycle de vie, en les attachant aux articles concernés, afin de construire et de gérer le maintien en condition opérationnelle dudit produit, ledit référentiel étant unifié, et ce qu'il comprend des outils de transformation (6), intégré ou interfacé au moyen d'interfaces bidirectionnelles, pour créer ou modifier des données techniques, calendaires ou financières afférentes au produit au sein du référentiel de données. 2. Système d'ingénierie logistique selon la revendication 1, caractérisé en ce que les outils de transformation (6) sont codés en langage XML ou en langage JAVA. 3. Système d'ingénierie logistique selon la revendication 1 ou 2, caractérisé en ce que toutes les données stockées dans le référentiel sont historisées en version et gérées en configuration. 4. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens pour capturer un contexte et en ce que toute donnée est associée à son contexte. 5. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce que l'implémentation du système est construite sur un environnement orienté objet. 6. Système d'ingénierie logistique selon la revendication 5, caractérisé en ce que les objets du système sont implémentés en utilisant les langages JAVA et J2EE. 7. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'un produit comprend des articles, des fonctions et des relations entre ces articles et ces fonctions. 8. Système d'ingénierie logistique selon la revendication 7, caractérisé en ce qu'une relation définit un lien fort ou un lien faible entre un organe et une fonction. 9. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce que les données du référentiel sont consultables en temps réel par les différents contributeurs. 10. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce que les contributeurs comprennent le responsable marketing ou commercial, le responsable de la définition, l'acheteur, le responsable de la production, le responsable du soutien logistique, l'utilisateur du produit, le client ainsi que toute personne intervenant sur le produit durant son cycle de vie. 11. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des rôles, associés aux différents contributeurs, définissant des prérogatives d'accès, des droits et des devoirs. 12. Système d'ingénierie logistique selon la revendication 11, caractérisé en ce qu'une donnée du référentiel de données est modifiable par un rôle et un seul en fonction du type de la donnée et de la phase du cycle de vie auquel elle se rattache. 13. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte et gère des demandes de travail (fonction de workflow ) permettant de planifier une tâche et/ou de réaliser une collaboration entre rôles. 14. Système d'ingénierie logistique selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il respecte et utilise le standard de codage, d'échange et de partage des données industrielles ISO 10303.