• Aucun résultat trouvé

Architecture fonctionnelle des agents du système

Chapitre III : Etat de l’art sur les approches d’interopérabilité sémantiques

III.7. Modélisation de l’ERP par les SMA et ontologies

III.7.3. Architecture fonctionnelle des agents du système

Parmi les innombrables et différents agents, nous nous limitons à l’agent interface utilisateur et à deux agents de domaines Achat/Appros pour représenter leurs architectures fonctionnelles.

III.7.3.1. Architecture Fonctionnelle : Agent interface utilisateur

Cet agent sert en quelque sort de complémentarité entre les agents du système et l’extérieur. Cet agent d’interface comprend un module de communication externe, une base de données utilisateur, un module de traitement et un module de communication interne dont nous détaillons brièvement les rôles ci-dessous :

Module communication externe : il sert à récupérer et rassembler les requêtes des agents externes pour les envoyer vers les agents du système.

Base de données utilisateur : elle contient toutes les croyances de l’agent interface utilisateur sur tous les autres agents et sur les agents externes (Fournisseur, Client, Banque, …etc.).

Module traitement : il permet l’acheminement des messages vers les agents concernés.

Module communication interne : garantit et assure l’interaction avec les différents agents de domaine.

Nous donnons ci-dessous les détails du fonctionnement :

1. L’agent externe s’occupe de l’envoi de la requête au système qui 2. est récupérée par le module communication externe qui la renvoie au

3. module traitement qui à son tour analyse et vérifie la requête avec la base de données utilisateur pour l'envoyer vers les agents de domaine concerné

4. Le module traitement passe à son tour la requête au

5. module communication interne qui renvoie la requête vers

6. l’agent de domaine concerné (Ex : Agent de domaine Achat/Appro) qui récupère la requête et l’envoie vers

7. le module communication interne, à son tour, passe le message au

8. module traitement qui analyse et vérifie la réponse avec la base de données utilisateur pour déterminer l’agent externe concerné. Il passe ensuite le message au

9. module traitement qui à son tour passe le message au module de communication externe qui au final renvoie le message à

10. l’agent externe concerné.

III.7.3.2. Architecture Fonctionnelle : Agents de domaines Achat/Appros

Architecture Fonctionnelle de l’agent de domaines Achat/Appros : Cet agent présente une

interface qui permet aux agents de domaine Achat/Appros de collaborer et de communiquer avec les autres agents du système. Il comprend les modules suivants :

Module communication inter-domaine : il s’agit de l’interface de l’agent qui interagira avec l'agent interface utilisateur et les autres agents de domaines.

BC Utilisateur Achat : il contient toutes les croyances de l’agent de domaine Achat/Appros sur les autres agents du système et sur les agents externes.

Gestionnaire de requête : il procède à l’analyse de la requête et l'envoyer vers les agents concernés.

Module communication intra-domaine : il est en interaction directe avec les différents

agents de domaine Achat/Appro (Ex : Agent stock).

Les détails du fonctionnement sont expliqué brièvement comme suit :

1. L’agent interface utilisateur renvoie la requête (Facture, BL) à l'agent de domaine Achat/Appros via le module communication inter-domaine ;

2. Ce dernier récupère à son tour la requête et l’envoie au gestionnaire de requête ;

3. Le gestionnaire de requête analyse la requête et la vérifie avec la base Utilisateur Achat avant de l'envoyer à l’agent concerné ;

4. Le gestionnaire de requête envoie la requête au module communication intra-domaines ;

5. Le module communication intra-domaine reçoit la requête qu’il transmet à son tour à

l’agent concerné (Ex : La facture à l'agent Achat ou bien la BL à l'agent Stock) ; 6. L’agent d'achat ou agent de stock selon que l’un ou l’autre soit concerné traite la requête

et donne la réponse au module communication intra-domaines ;

7. Le module communication intra-domaines reçoit la réponse et la communique, à son

tour, au gestionnaire de la requête ;

8. Ce dernier analyse la réponse et la transmet au module communication inter-domaine ;

9. En fin, l’agent utilisateur reçoit la réponse de la requête et l’envoie vers l’agent externe concerné.

7.2.2. Architecture Fonctionnelle : Agent Achat

Cet agent est responsable de la gestion des achats de l’entreprise, de la demande d’achat à sa réception et sa comptabilisation. Son rôle comporte quatre modules : 1- Un module de communication, 2- Un moteur de raisonnement, 3- Une Base de Connaissance achat, 4- Une BD achat. Leurs rôles sont définis brièvement comme suit :

Module de communication : il assure en fait les interactions des messages avec l’agent de domaine Achat\Appro et avec les autres agents des services.

Moteur de raisonnement : il contrôle et supervise l’exécution de ses actions.

Base de Connaissance Achat : comprend un ensemble de critère définissant les conditions des achats, autrement dit les critères aux choix des produits (prix, les marques et leurs caractéristiques), et aussi les critères liés aux choix des offres de fournisseurs (prix du produit, le garantie, la qualité, la gamme de produits, délai de livraison, la disponibilité).

BD achat : contient et englobe toutes les données inhérent aux achats repaties comme

suit :

 Toutes les données concernant les fournisseurs (nom, localisation, tel, fonction, code comptable, etc.) ;

 Toutes les informations relatives à la demande d’achat (N°, Demandeur, Article, Quantité, Prix unitaire, Date, Prix total, etc.) ;

 Toutes les informations concernant les contrats établis (Article, Prix, délai de livraison, Durée du contrat, etc.) ;

 Toutes les données relatives aux articles et produits à acheter (Nom, famille, sous famille, tarif de vente, tarif d’achat, etc.) ;

 Toutes les informations relatives au bon de commande (N°, date, fournisseur, Article, Quantité, marque, Prix, etc.).

Dans ce qui suit, on essayera d’apporter plus de clarification au fonctionnement de l’agent achat dans le cas d’un établissement de contrat ou processus d’appel d’offre. Ce cas précis illustre le fonctionnement de l’agent achat lors d'un appel d'offre lancé par une entreprise pour acquérir des produits ou des articles manquants, On peut donc souligner que le résultat de ce processus est l’établissement d'un contrat entre d’un côté l’entreprise et de l’autre côté le fournisseur. Nous décrivons son fonctionnement à travers les étapes suivantes :

1. Identification d’un besoin : l’agent demandeur qu’il soit l’agent Stock ou l’agent de

domaine Achat/Appro, signale les produits ou les articles manquants par l’envoi d’un message explicite (DA) à l’agent achat, cela dans ce cas où le produit demandé ne figure pas dans un contrat entre l’acheteur et le fournisseur).

2. Recherche d’un produit : l’agent achat analyse tout en vérifiant si la demande d’achat

est en conformité avec les critères de base de connaissance concernant les produits à acheter, qu’il trouve que le résultat de l’ensemble des produits est conforme et satisfaisant les critères de choix (prix, les marques et leurs caractéristiques), puis il les stocke dans la BD d'achat.

3. Recherche d’un fournisseur (Comparaison des offres de fournisseurs) : les choix

des produits et leurs caractéristiques étant établis, l’agent achat lance la procédure d’appel d’offre. Il reçoit en retour les offres des fournisseurs via le module de communication et les stocke dans la BD d'achat. L’agent achat procède à une comparaison entre les différentes offres proposées par les fournisseurs en se basant sur les critères définis dans la base de connaissance (prix du produit, la garantie, la qualité, la gamme de produits, le délai de livraison, la disponibilité) tout cela dans le but de chercher le meilleur fournisseur qui fournira les meilleurs produits à l’entreprise.

4. Négociation Acheteur-fournisseur : Cette quatrième étape a trait à la négociation entre

l’agent achat et le fournisseur en se mettant d’accord sur le prix du produit et les autres termes et condition de transaction (les contraintes de temps, les contraintes géographiques, la modalité de paiement). Le module de communication a ici un rôle essentiel dans cette étape qui permet d'échanger les messages entre l’agent achat et le fournisseur en passant par l’agent de domaine Achat/Appros et l’agent utilisateur. Les résultats de cette quatrième étape sont :

1- L’établissement des contrats entre l'acheteur et le fournisseur,

2- L'enregistrement des contrats dans la BD d'achat et en fin,

3- l’achat et la livraison du produit.

5. L’évaluation après-achat : la mission et la responsabilité de l’agent achat se

prolongent après l’achat effectif du produit : Service après-vente et des évaluations relatives aux achats en se basant bien entendu sur l’historique des achats établis.

Le schéma ci-dessous présente le fonctionnement de l’Agent Achat et/ou le acheminement de la mission de l’agent achat dans le cas d’un appel d’offre.

III.3. Conclusion

Dans ce chapitre, nous sommes efforcés de présenter les différentes classifications des hétérogénéités sémantiques des services Web, les approches de description de la sémantique de ces derniers, les médiations qui résolvent les confits inhérents, et une classification des approches d’interopérabilité et d’intégration des services Web pour dresser l’interopérabilité sémantique des systèmes d’information à base d’ERP. A l’issue de cette classification, nous avons retenu surtout l’utilisation des approches hybrides basées sur les services web, ontologie et système multi-agents et au final nous avons présenté une étude comparative des travaux existants.

Le chapitre suivant sera consacré à notre contribution qui concernera le niveau d’interopérabilité sémantique, tout en proposant une approche et une architecture flexible et orientées services Web pour l’interopérabilité des ERPs.

Chapitre IV : Une approche sémantique pour