Ingénierie des systèmes d'information

Sur le plan de l'organisation et donc des métiers, les années 80 se caractérisent par une prise de conscience d'une nécessaire reconception de l'architecture générale de l'informatique au sein des entreprises. Cette reconception doit assurer la cohérence générale des informations, préserver l'évolutivité des modes de gestion et d'organisation, permettre l'introduction de nouvelles technologies sans compromettre l'acquis et enfin associer, dans leurs responsabilités respectives, décideurs, utilisateurs et informaticiens.

C'est dans ce contexte qu'ont émergé la notion de système d'information et la nécessité de méthode complète de conception et de spécification permettant l'informatisation des systèmes d'information. L'approche systémique a largement contribué à ce renouveau et la méthode Merise y puise ses racines.

Il s'agit alors d'appréhender le métier de l'organisation afin d'une part de cerner la mémoire centralisée de l'organisation et d'autre part de permettre au travers de cette dernière de coordonner les activités de l'organisation. Une modélisation des données et des activités permet d'y arriver en ayant cependant recours à une modélisation à plusieurs niveaux d'abstraction cristallisant des préoccupations managériales et organisationnelles associées à la compréhension du métier et des préoccupations techniques (informatiques).

Sur le plan informatique, les bases de données commencent a être opérationnelles et permettent de supporter cette mémoire centralisée nécessaire à cette coordination de l'organisation. La modélisation des données, proposant des formalismes et des outils pour décrire les données indépendamment de leurs utilisations dans des traitements, favorise ainsi la mise en œuvre des bases de données. Les SGBD relationnels s'imposent à la fin de cette décennie. Des environnements de développement d'applications autour de ces bases de données font leur apparition. Les réseaux locaux apparaissent et facilitent la coordination de l'organisation.

Merise, de par son cadre de modélisation et sa démarche spécifiques adaptés à la prise en compte du métier, apparaît alors comme la réponse adaptée à la conception de systèmes d'information organisationnels.

Les années 90 sont caractérisées par un accroissement de la concurrence, une recherche de productivité qui conduira sur le plan de l'organisation et du métier à une remise en cause des modèles et pratiques organisationnels qui est l'objet du BPR. Le cadre de modélisation proposé par Merise, de par ses modèles d'activité positionnés à des niveaux d'abstraction (conceptuel - managérial, organisationnel) permet une modélisation et une analyse pertinente de ces modèles et pratiques organisationnels, comme le développe le chapitre 19Chapitre 19 Merise et le BPR de l'ouvrage.

Ces différentes évolutions du métier conduisent à reconsidérer le caractère centralisé du système d'information. L'organisation se structure en centres de profit plus ou moins autonomes, disposant de leurs propres informations, voire de leurs propres systèmes d'information. Il s'agit alors notamment de gérer les modalités de partages des informations de ces systèmes. De plus, les systèmes d'information sont de plus en plus complexes. Les besoins des organisations en information pour l'aide à la décision s'élargissent notamment à des entrepôts de données (Data-Warehouses), historisés sur plusieurs années.

Sur le plan technique, le mariage des bases de données et des réseaux est suffisamment solide pour pouvoir supporter de telles évolutions organisationnelles. C'est l'apparition des architectures client-serveur, des bases de données distribuées et réparties. Les performances des SGBD, notamment obtenues par le parallélisme, permettent maintenant de gérer efficacement des bases de données très importantes, notamment celles associées à des entrepôts de données.

Merise évolue pour répondre aux spécificités de ces nouveaux systèmes d'information dont les organisations ont besoin. Pour cela il est nécessaire d'en réviser le cadre de modélisation (passage de trois à quatre niveaux d'abstraction) et d'étendre les formalismes de données et de traitements. Ces extensions s'inspirent principalement des méthodes et notations orientées objet proposées dans le domaine du génie logiciel, en conception logicielle. Ces évolutions conduisent à la deuxième génération de Merise. Merise permet alors d'appréhender de façon satisfaisante ces nouveaux besoins et de mettre en œuvre ces nouvelles technologies. On peut rajouter que cette nouvelle génération la renforce encore dans sa spécificité en distinguant bien le SIO associé au métier de l'organisation, du SII associé à la mise en œuvre de l'outil informatique.

La fin des années 90 voit la confirmation des méthodes de conception logicielle orientées objet comme OMT et l'apparition de la notation objet unifiée UML. Un positionnement de Merise par rapport à ces méthodes ou notations est nécessaire, ce que nous allons tenter de faire.

Largement pratiquée dans de nombreux secteurs de l'informatique temps réel et de l'ingénierie logicielle, l'approche objet offre une manière claire de concevoir une architecture modulaire, encapsulant la complexité et facilitant l'implémentation multiplateforme. Elle permet une flexibilité technique accrue et une meilleure ouverture aux nouvelles technologies telles que le multimédia. Elle touche aujourd'hui les systèmes d'exploitation, le middleware des architectures client-serveur et de plus en plus l'informatique de gestion. Grâce aux efforts de standardisation et de normalisation conduits notamment sous l'égide de l'Object Management Group (OMG), on peut s'attendre à ce que les progrès de l'approche Objet s'accélèrent.

À la fin des années 90, l'approche objet est réellement opérationnelle dans le génie logiciel, tant au niveau de la conception logicielle (conception orientée objet) qu'au niveau de la réalisation (programmation orientée objet). L'approche objet s'est particulièrement distinguée dans le domaine des interfaces homme-machine. Dans la conception et la réalisation de ces interfaces, basées sur le paradigme objet-action dans lequel l'utilisateur désigne un objet puis choisit le service qu'il veut en obtenir, l'objet encapsulant ses services est parfaitement adapté. L'approche objet a ainsi permis d'offrir à l'utilisateur une interface ergonomique et intuitive conforme à son contexte d'activité.

Toutefois, nous n'en sommes pas encore au tout objet. En effet, bien que très séduisants, les systèmes de bases de données orientés objet sont aujourd'hui encore au stade préindustriel. Ils ne peuvent apporter une réponse satisfaisante à la gestion d'un volume important de données structurées et partagées sur lesquelles reposent les systèmes d'information des entreprises actuelles. Dans cette évolution des bases de données vers l'objet, les praticiens qui ont ces dernières années majoritairement opté pour des SGBD relationnels mettent actuellement plus d'espoir dans une évolution en cours des SGBD Relationnels vers l'objet que dans des SGBD révolutionnairement objet.

L'approche objet dans les méthodes de conception de système d'information nous semble avoir deux intérêts essentiels : la réutilisation d'objets tant au niveau du SII que du SIO et la continuité méthodologique (démarche et formalismes) centrée sur la notion d'objet entre la conception du SIO et celle du SII. Une telle évolution serait une réponse aux actuelles préoccupations majeures des responsables systèmes d'information, à savoir la migration vers l'objet, le choix des applications et des « charpentes » d'objets à développer, ceci en adéquation avec les besoins de l'organisation et le Business Process Reengineering (BPR).

Actuellement, deux voies d'évolution possibles de Merise et des méthodes traditionnelles de conception de systèmes d'information vers l'objet nous paraissent possibles :

• La première voie, que nous nommerons « transition vers l'objet », se veut pragmatique, opérationnelle à court terme et préserve une grande partie des investissements méthodologiques antérieurs. Elle consiste à définir de façon claire comment passer de la spécification d'un SIO réalisé selon le cadre méthodologique merisien (celui-ci pouvant être éventuellement aménagé) à une spécification du SII orientée objet. Dans cette voie, il n'y a certes pas de continuité méthodologique objet, mais plutôt une transition méthodologique vers une architecture logicielle objet.
• La seconde voie, que l'on peut appeler « évolution vers l'objet », est plus radicale et conduit à une remise en cause profonde de Merise, permettant de traiter complètement la réutilisation et la continuité méthodologique entre le SIO et le SII. La réutilisation, comme la continuité méthodologique, reposerait dans cette voie sur l'introduction du concept d'objet au niveau SIO que l'on pourrait nommer « objet métier » et sa dérivation vers le concept d'objet du génie logiciel associé au SII, ou « objet logiciel ou technique ».

La première voie, bien que modeste, nous apparaît la plus réaliste aujourd'hui. En effet, dans le contexte actuel et pour les raisons que nous avons précédemment évoquées, une remise en cause radicale nous apparaît difficilement envisageable pour la plupart des entreprises. Une évolution méthodologique vers l'approche objet qui s'effectuerait par transition, en s'appuyant sur des bases méthodologiques acquises telles que Merise, rencontrerait certainement l'adhésion des praticiens.

Un tel couplage est d'autant plus facilité pour la méthode OMT (et UML) qui a retenu pour l'expression des diagrammes de classes (modèle objet) un formalisme graphique constituant une extension du formalisme Entité-Relation proposé par Merise. Pour plus de détails sur ce couplage de la méthode Merise avec la méthode OMT, nous renvoyons le lecteur à un article détaillant les règles et conseils de passage des modèles organisationnels Merise (MOT, MOD) aux trois modèles de OMT (Modèles Objet, Dynamique et Fonctionnel) [Espinasse & Nanci 97].

Dans la seconde voie, bien des aspects sont actuellement imprécis et relèvent encore de la recherche. Cependant, comme l'a développé le chapitre 9 de cette quatrième édition, « Cycle de vie des objets et des objets métierChapitre 9 Cycle de vie des objets et objets métiers », l'identification, la formalisation et bientôt la réutilisation d'objets métier au niveau du SIO se font jour, premiers pas vers une ingénierie à base de composants.

Dans la foulée de la méthode OMT, la notation UML semble s'imposer. Sans conteste, cette notation constitue une avancée significative pour les méthodes de conception logicielle en leur proposant un standard de notation qui leur manquait. Ce standard de notation se présente comme une boîte à outils de modèles et de diagrammes permettant la spécification d'une conception objet.

Notons que cette notation ambitionne de contribuer à la modélisation objet de tout système complexe logiciel ou non. En ce qui concerne le domaine du logiciel, la richesse de cette boite à outils permet de cerner les aspects structurels, dynamiques et fonctionnels d'un logiciel, tant à un niveau analyse (analyse des besoins, spécification fonctionnelle), qu'à un niveau conception (architecture logicielle, conception générale et détaillée), qu'enfin à un niveau implémentation. Nous ne rentrerons pas dans une discussion plutôt stérile sur la puissance de tel ou tel formalisme pour cerner tel ou tel aspect.

Cette richesse de notation conduit certains à tenter de l'utiliser pour la conception de systèmes d'information, c'est-à-dire pour modéliser le SIO. Le risque nous apparaît grand, car il peut conduire à remettre en cause l'approche systémique originale de Merise propice à appréhender le métier de l'organisation. Ainsi, dans la recherche d'une continuité de modélisation centrée sur le concept d'objet, le cadre de modélisation associé à UML se voulant universel, il n'est pas adapté à la conception de systèmes d'information organisationnels.

Ainsi, la nécessité de niveaux d'abstraction que préconise Merise et qui regroupent des préoccupations homogènes, spécifiques à la problématique de ces systèmes, notamment relatives au métier, à savoir des préoccupations managériales et des préoccupations organisationnelles, est remise en cause. Peut-on raisonnablement faire l'économie de ces niveaux d'abstraction spécifiques lorsqu'ils apparaissent de plus en plus pertinents et d'actualité, comme nous l'avons vu dans le chapitre 9Chapitre 9 Cycle de vie des objets et objets métiers pour accompagner le BPR ?

Certes non. Leur disparition conduirait au divorce de l'informatique, de l'organisation et du management, ce que nous avions avant Merise. Nous ne concevons pas des systèmes d'information pour mettre en œuvre des techniques informatiques, concevoir et réaliser des logiciels, mais pour supporter des organisations en constante évolution, tant dans leurs pratiques organisationnelles que managériales associées à l'exercice de leur métier, afin de les aider dans leur adaptation à un environnement concurrentiel.

Dans cette adaptation, au-delà d'un problème de notation, il nous apparaît bien plus important de pouvoir, de façon rationnelle, accroître la qualité des logiciels impliqués dans ces systèmes d'information, ainsi que la performance des processus utilisés pour les concevoir et les réaliser. Cette qualité et cette performance ne peuvent être améliorées que par une approche par réutilisation de composants, comme cela a déjà été le cas dans bien d'autres domaines d'ingénierie.

Ainsi, le problème central pour l'ingénierie des systèmes d'information est bien celui de la réutilisation et non celui d'une continuité de formalisme - de notation -, permettant de modéliser à la fois le SIO et le SII. Si l'approche objet actuellement associée au génie logiciel apparaît adaptée à une réutilisation en conception et réalisation logicielle, elle ne l'est pas encore pour la conception de systèmes d'information organisationnels en ne prenant pas en compte toute la spécificité de leur complexité, notamment celle associée au métier.

En conséquence, l'adoption d'une notation adaptée au génie logiciel, comme UML, pour la conception de systèmes d'information organisationnels, ne résout en rien notre problème. Par contre, une ingénierie des systèmes d'information à base de composants nous semble la voie à suivre.

Ce début de siècle est caractérisé par la globalisation de l'économie. La performance des entreprises des pays industrialisés est liée à la puissance de leur organisation interne et par là même à celle des systèmes d'information qui la supportent. Le contexte concurrentiel de plus en plus vif conduit les entreprises à une recherche constante de productivité à tous les niveaux, mais aussi à un accroissement de flexibilité, d'adaptabilité et de réactivité. Les entreprises sont pour cela conduites à une permanente remise en cause de leurs modes de gestion et d'organisation (BPR).

Les nouveaux modes de gestion et d'organisation privilégiés par les entreprises sont principalement caractérisés par des processus décisionnels de complexité croissante, due notamment au raccourcissement constant du cycle de vie des produits. Un tel raccourcissement nécessite la coordination de processus décisionnels distribués, parfois le temps d'un projet, entre de nombreuses équipes de conception, de fabrication, de logistique, de marketing, de finances… internes à l'entreprise ou partenaires de celle-ci. De nouveaux types d'organisation apparaissent ; citons notamment l'entreprise réseau, l'entreprise étendue ou encore l'entreprise virtuelle.

Les systèmes d'information supportant ces nouveaux types d'organisation, en permanente évolution, sont nécessairement distribués pour prendre en compte dans l'entreprise tout fait nouveau jusqu'à complète répercussion de l'ensemble de ses effets. Cette prise en compte nécessite l'usage d'environnements informatisés eux-mêmes distribués et coopératifs dans lesquels les réseaux (d'Intranet à Internet) tiennent une place centrale au même titre que les données mémorisées, augmentant d'autant la complexité de ces systèmes d'information. Dans la compréhension de la complexité de ces systèmes d'informations à concevoir, « formées par l'interaction entre leurs propres parties » [Morin 1977], le problème essentiel est celui de l'autonomie de leurs parties et de leur coopération. Cette coopération est essentielle dans les architectures distribuées. Comment faire coopérer des sous-systèmes, des unités, des composants conçus et maintenus par des équipes indépendantes ?

Comme nous l'avons déjà évoqué, l'accroissement de la qualité des systèmes d'information, ainsi que la performance des processus utilisés pour les concevoir et les réaliser, passe par la réutilisation de composants. Par composant, nous entendons bien sûr les composants logiciels, mais aussi les composants de spécification de conception. Il est clair que ces grands types de composants sont de plus en plus en étroite relation.

D'une façon générale, les composants devraient jouer un rôle de premier plan dans l'industrie du logiciel. On en attend les mêmes bénéfices que ceux promis par l'objet : réutilisabilité, interopérabilité, productivité, qualité, maintenabilité… Mais le marché du développement à base de composants n'en est qu'à ses débuts et la pratique actuelle de l'ingénierie à base de composants est difficile à estimer. Une enquête citée par [Sodhi & al.98] sur un ensemble d'organisations ayant mis en place des programmes de réutilisation fait apparaître pour ces dernières des bénéfices importants (50 % de réduction en temps d'intégration, 20 à 30 % d'amélioration de la qualité).

De même, le Gartner Group prévoit que le développement à base de composants devrait s'imposer dans quelques années comme la forme d'ingénierie majeure (en 2003, 50 % des développements devraient se faire à partir de composants) et que les revenus générés par les ventes de logiciels à base de composants et par les services associés devraient augmenter de manière très significative [kiely 98]. Cette enquête montre aussi que la réutilisation est pratiquée avec des méthodes et des outils empiriques et qu'il existe aujourd'hui un réel besoin de rendre la réutilisation plus systématique dans l'ingénierie des systèmes d'information.

Le cabinet IDC distingue pour sa part un segment particulièrement dynamique pour le développement des composants, celui des outils de développement d'applications incluant des produits tels que les L3G, les L4G, les SGBD, les composants logiciels et les outils de construction et d'assemblage de composants, suit ensuite le segment des « middlewares ».

On peut distinguer différents types de composants se différenciant par leur granularité, par leur niveau d'abstraction (composants logiciels, composants de conception, composants de métier) ou encore par la nature de la connaissance qu'ils permettent de réutiliser. Les composants peuvent ainsi prendre la forme de classes d'objets individuelles ou de structures de connaissance très complexes. Certains composants fournissent des fragments de produit (logiciel, architecture, schéma conceptuel…), d'autres décrivent des fragments de démarche [Cauvet & al. 00].

Dans cette ingénierie à base de composants, on distingue deux problématiques complémentaires : celle associée au développement d'un système de réutilisation (« design for reuse ») et celle relative au développement d'un système particulier par réutilisation (« design by reuse ») [kang & al. 90] :

• Le développement d'un système de réutilisation met en œuvre des tâches d'identification de ressources réutilisables, de spécification et d'organisation de composants, mais aussi d'implantation d'un ensemble de composants au sein d'un système de réutilisation. Les recherches concernent la définition de modèles et de langages pour la spécification de composants réutilisables permettant la représentation de connaissances génériques. Des méthodes et des outils logiciels assistant l'identification de ressources réutilisables et la conception / réalisation de systèmes de réutilisation doivent également être développés.
• Le développement d'un système, par exemple un SI, par réutilisation de composants nécessite une reformulation des processus usuels d'ingénierie utilisés pour le développement de ce système, ainsi que des outils de développement intégrant de manière systématique la réutilisation de composants. Un tel développement consiste à identifier et organiser les composants en fonction d'une stratégie de réutilisation, de contraintes de déploiement et de composants disponibles pouvant avoir différentes granularités, comme un composant métier élémentaire ou une application complète.

Divers modèles (et langages) de composants sont dès aujourd'hui proposés, citons notamment les abstractions de domaine [Maiden 93], les patrons (« design pattern ») [Gamma &al. 95] et les canevas (« frameworks ») [Johnson 93]. D'une façon générale et comme le souligne [Cauvet & al. 00], ces modèles tout d'abord s'orientent de plus en plus vers des formes de composants permettant la réutilisation de produits de spécification et de produits de conception, en conséquence vers le métier associé à l'applicatif à développer. Ensuite, ils intègrent, dans la spécification des composants, des propriétés permettant de guider leur réutilisation, facilitant par exemple leur recherche, leur adaptation et leur assemblage.

Stimulée par le succès de Java, la technologie objet se répand et jette les bases d'une industrie du logiciel à base de composants et tournée vers le métier des utilisateurs. Les composants métier ou objets métier représentent la forme la plus élaborée de la réutilisation pour laquelle les enjeux techniques et surtout commerciaux sont considérables. Notons que l'OMG (Object Management Group) et l'OAG (Open Application Group) travaillent chacun de leur côté à la standardisation de composants métier.

De même que les « widgets » sont devenus incontournables pour le développement d'interfaces graphiques, les objets métier sont les briques applicatives de base pour l'assemblage d'applications qui touche à un métier ou à un processus de l'organisation. Si les premiers s'adressent aux programmeurs, les objets métier s'adressent aux analystes, aux utilisateurs avancés et aux éditeurs de logiciels ou de progiciels, c'est-à-dire à l'organisation et son métier (l'entreprise) plutôt qu'uniquement aux informaticiens.

L'offre en composants métier en est à ses débuts. Parmi les acteurs pionniers, on trouve des sociétés comme Soleri-Cigel, Nat Systems, Synon et Lyon Consultants (IMR). De même, citons l'investissement considérable d'IBM sur le projet San Francisco [Carey & al. 00] qui regroupe plus de cinquante éditeurs majeurs autour de la construction de bibliothèques de composants métier réutilisables pour le développement de progiciels Client/Serveur en Java. Ces composants métiers définis en tant que « design patterns » ont conduit au développement de bibliothèques de composants métier réutilisables en Java et organisés en « framework ». La première mouture (300 composants Java), sortie en 1997, mettait à disposition l'infrastructure technique nommée « Foundation », les services applicatifs généraux appelés « Common Business Objects » ainsi que la première brique, consacrée à la comptabilité générale de la couche métier (une centaine de composants). Cette brique appelée « Core Business Processes » est destinée à recevoir des processus regroupés en sous-systèmes extensibles ou « frameworks » applicatifs. La deuxième mouture sortie en 1998 rajoute deux « frameworks », l'un consacré aux commandes et l'autre à la gestion des stocks. La troisième rajoute le traitement des effets à recevoir et des effets à payer. Les composants Java issus du projet commencent à être utilisés (plusieurs centaines de licences vendues) et ont dès à présent permis le développement de nombreuses applications.

Rappelons que (cf. chapitre 9Chapitre 9 Cycle de vie des objets et objets métiers) la notion d'objet métier est progressivement apparue dans la méthode Merise au début de la décennie 90 comme une extension de la modélisation conceptuelle des données. Plus de vingt années de pratique nous conduisent à penser que Merise nous offre un cadre de modélisation propice à une ingénierie par composants et plus particulièrement par composants métier.

En effet, dès son origine, Merise s'est appliquée à concilier l'organisation, c'est- à-dire le métier, avec l'informatique. Le cadre de modélisation structuré en niveaux d'abstraction ou de préoccupation et plus particulièrement les niveaux conceptuel et organisationnel tels que définis dans Merise deuxième génération, nous apparaissent vraiment adaptés à la modélisation du métier et par là même à l'identification d'invariants métier, de composants ou objets métier. Cette conviction est d'ailleurs confortée par l'usage de Merise pour le BPR dont la finalité est essentiellement de modéliser les pratiques organisationnelles du métier (cf. chapitre 19Chapitre 19 Merise et le BPR).

Dans l'ingénierie à base de composants, nous avons vu que l'on pouvait distinguer deux problématiques complémentaires : celle du développement d'un système de réutilisation et celle du développement d'un système particulier par réutilisation. Dans le cadre de cet ouvrage, nous nous plaçons essentiellement dans la première problématique. Le développement d'un système de réutilisation nécessite tout d'abord l'identification des ressources réutilisables les composants métier, leur spécification et leur organisation.

Un composant métier de conception en ingénierie des systèmes d'information spécifie un ensemble de services, mais sans être lié à une application particulière, par exemple, un objet métier facture fournissant un service permettant de saisir un encaissement. Un même composant peut être réutilisé pour concevoir différents systèmes particuliers, par exemple un composant métier facture gérant des factures peut être réutilisé pour concevoir différentes applications de facturation.

C'est à l'identification, la spécification et l'organisation de composants métiers de conception que nous pensons dès à présent avoir contribué dans le chapitre 9Chapitre 9 Cycle de vie des objets et objets métiers. Certes, cette réflexion n'en est qu'à ses débuts. Un composant n'est pas forcément un objet, même si les concepts objet s'appliquent assez logiquement aux composants : encapsulation, classification (héritage), polymorphisme.

Nous avons, dans le cadre de cette quatrième édition, présenté tout d'abord deux différentes perspectives méthodologiques associées à l'objet métier : la macro-modélisation et la modélisation intégrative. La macro-modélisation se limite à la modélisation des données (structure) de l'objet métier. La modélisation intégrative ajoute à cet aspect structurel l'ensemble des autres aspects de sa modélisation. L'objet métier apparaît alors comme l'intégration de diverses facettes d'un concept du métier qu'explicitent les différentes modélisations formalisées : son comportement dynamique (CVO), son utilisation fonctionnelle (MCT - MOT) et ses présentations (maquettes d'IHM).

La perspective de la macro-modélisation nous a semblé, dans l'état actuel de nos réflexions, la plus praticable et nous avons proposé, dans le cadre de Merise, des éléments méthodologiques permettant tout d'abord la modélisation d'objets métiers (nouvelles extensions du formalisme Entité-relation) et ensuite d'accompagner le concepteur dans l'élaboration de ces modèles en lui proposant une démarche spécifique (élaboration par composition et par décomposition).

Dès à présent, ces nouveaux éléments méthodologiques devraient permettre au concepteur merisien une certaine rationalisation de la conception de modèle de données (MCD) au travers d'une meilleure intégration (interne et externe) de ces objets métier conduisant à une réduction des coûts de développement et d'évolution des systèmes d'information.

La définition complète d'un système de réutilisation (« design for reuse ») nécessiterait de passer de l'approche macro-modélisation à l'approche intégratrice prenant en compte les autres composantes de l'objet métier (comportement, fonctionnement, présentation), y compris pour les autres niveaux (organisationnel et logique). Ensuite, il faudrait envisager l'implantation d'un tel système mettant à disposition du concepteur un ensemble (bibliothèques) de composants métier. Une telle implantation pourrait s'appuyer sur l'atelier Merise Win'design.

Un tel système étant développé, l'étape suivante consisterait alors à reformuler les processus d'ingénierie associés au développement d'un système d'information particulier à partir des bibliothèques de composants métiers disponibles (« design by reuse »). Il s'agirait entre autres d'apporter une aide méthodologique au concepteur dans le choix des composants, dans leur adaptation et leur assemblage, ceci selon des stratégies de réutilisation encore à définir.

Ainsi, l'approche objets métier peut désormais s'inscrire comme un complément et une évolution prometteuse de l'approche « merisienne » classique en ingénierie de systèmes d'information et, comme diraient certains, « sur le métier remettez votre objet… ».