Zone Back

Zone Back Zone Front DB Serveur Back Serveur Front

♀

♀

♀

Figure . – Architecture physique et organisation des différentes plates-formes ... Architecture de la plate-forme

L’architecture de Kyriba ayant été précisée, il est désormais possible de décrire l’architecture de la plate-forme.

La Figure . représente l’architecture fonctionnelle de la plate-forme. Celle-ci s’appuie sur Kyriba et l’utilise comme bibliothèque logicielle.

La plate-forme est divisée en plusieurs modules. A l’instar de Kyriba, elle s’appuie sur un ensemble de mécanismes, regroupés dans le module services techniques. Un second module (Data Transfer Ob-ject), lui aussi technique, permet la communication entre les différentes instances. Toute interaction entre les instances passe forcément par ce module.

Sur ces services techniques est construite la logique métier. Le module kin-common est le module métier contenant ce qui est commun à tous les clients, investisseurs comme fournisseurs. Trois modules héritent et étendent celui-ci. Deux de ces trois modules sont ceux de clients particuliers, l’un pour l’investisseur (purchaser) et l’autre pour le cédant (seller). Enfin, un package est réservé au program assistant, rôle de l’utilisateur système qui gère la place de marché.

Notons que du point de vue de Kyriba, Kinvo est un module supplémentaire, qui s’appuie lui aussi sur ses modules communs.

Kyriba Services techniques

DTO kin-common

Seller Purchaser Program Assistant

Kinvo

Figure . – Architecture fonctionnelle et organisation des modules

Architecture de déploiement Comme le montre la Figure ., Kinvo apporte un changement assez important à l’architecture de déploiement de Kyriba. En effet, afin que les différentes instances puissent communiquer de façon sécurisée via Internet, il est nécessaire de relier les éléments par un Virtual Private Network (VPN).

D’un point de vue technologique, il n’y a pas de différence majeure entre Kyriba et Kinvo. Le module de communication de la plate-forme qui permet aux différentes instances de communiquer entre elles utilise lui-même les Enterprise Java Beans, mais dans le contexte du VPN.

.. Discussion

Dans cette section, nous avons présenté une ontologie servant de modèle à notre plate-forme mul-ti-agents pour le commerce de factures, de bons de commande et de stocks. Nous nous sommes pour cela appuyés sur les architectures décrites dans la littérature. Nous avons également montré quelle mé-thodologie nous avons adoptée afin de concevoir cette ontologie, ainsi que les outils et formats que nous avons utilisés pour son implémentation. Enfin, nous avons décrit les différentes parties d’OntoMASK, et la façon dont elles sont reliées entre elles.

Notre ontologie, OntoMASK a été conçue comme modélisation de la plate-forme que nous implé-mentons, et nous avons pris cet élément en compte lors de sa conception. Nous avons notamment dû répondre à un double critère de rigueur et de simplicité.

Nous avons également explicité les composantes techniques de cette plate-forme. Celle-ci permet à des acteurs présents sur plusieurs serveurs de négocier malgré tout les uns avec les autres. La place de marché, implémentée en Java, bénéficie de l’architecture fournie par Kyriba App et des services proposés par ses bibliothèques. Elle reste cependant spécifique, tant dans le fait qu’elle permet aux acteurs de négocier depuis différents serveurs que parce qu’elle implémente ses propres fonctionnalités.

.. CONCLUSION DB Serveur Back Serveur Front

♀

♀

♀

♀

Figure . – Architecture physique et modifications amenées par la plate-forme

. Conclusion

La plate-forme que nous avons automatisé a pour objectif la réduction du besoin en fonds de roulement. Il s’agit d’une place de marché utilisable par les entreprises pour revendre leurs créances, stocks ou bons de commande et qui leur servira à financer leur BFR auprès d’investisseurs (banques ou fonds). Nous sommes donc dans un contexte particulier : d’une part, il s’agit de commerce BB, d’autre part, les acteurs présents sur la plate-forme en font une place de marché très à part. Bien que la plate-forme propose du BB, les moyens des acheteurs et ceux des vendeurs sont complètement différentes : d’un côté, les acheteurs sont des banques ou des fonds d’investissements dotés d’importants fonds. De l’autre, la cible de la plate-forme est constituée de PME, parmi lesquelles certaines viennent parce qu’il leur est difficile d’emprunter auprès de banques. Cette asymétrie de moyen doit être prise en considération : il ne faut pas qu’elle permette aux acheteurs d’abuser de leur supériorité afin de tirer des profits aux dépens des vendeurs. Le but est qu’elle soit profitable à tous. Ces aspects ont nécessairement un impact important sur le protocole de négociation, qui est discuté au chapitre , ainsi que sur l’agent de négociation, exposé au chapitre .

Par rapport aux places de marché existantes que nous avons décrites dans la section ., Kinvo se positionne ainsi :

• les clients sont des entreprises. Il s’agit de PME pour les vendeurs et d’investisseurs pour les 

clients. On est donc dans un cadre BB,

• le protocole est décrit dans le Chapitre . Nous en donnons plusieurs implémentations possibles. Dans tous les cas, il s’agit d’une variante du bargaining ayant un nombre fixe de tours. L’en-semble des variantes de ce protocole le classent dans les catégories 1:1 et 1:n. Le nombre de tours considéré est fixe,

• nous considérons le cas multi-attributs, ainsi que le cas mono-attribut. Le protocole que nous avons conçu supporte ces deux cas, et l’agent de négociation présenté dans la Chapitre  est capable de négocier dans ces deux contextes. Néanmoins, notre protocole impose une limitation dans le cas multi-attribut : il ne peut s’agir que d’attributs quantitatifs, et il est préférable qu’un prix en fasse partie,

• les agents sont dotés de fonctions d’utilité, i.e. de préférences souples.

En ce qui concerne les aspects techniques, notre plate-forme est implémentée, comme beaucoup d’autres, en Java. En revanche, les problématiques métier imposent une architecture matérielle et réseau particulière. D’autre part, l’architecture est couplée à Kyriba App, le portail de gestion de trésorerie de Kyriba. L’intégration d’un système multi-agents n’est donc pas évidente, et c’est à cette fin que nous avons conçu une ontologie, qui éclaire les liens entre la plate-forme d’une part et le système multi-agents de négociation d’autre part. Cette ontologie sert de point de départ au développement de notre protocole aussi bien que de notre agent, en définissant ses besoins.