Génie logiciel en système comptable OHADA (Organisation pour l'harmonisation en Afrique du droit des affaires ). Conception et mise en place d'un logiciel de gestion de stock intégré à la comptabilité

UNIVERSITE ADVENTISTE DE LUKANGA
« UNILUK »
B.P. 180 BUTEMBO/RDC
REPUBLIQUE DEMOCRATIQUE DU CONGO

FACULTE DES SCIENCES ECONOMIQUES ET DE GESTION
DEPARTEMENT DE GESTION INFORMATIQUE





« GENIE LOGICIEL EN SYSTEME COMPTABLE OHADA :
CONCEPTION D'UN LOGICIEL DE GESTION DE STOCKS
INTEGRE A LA COMPTABILITE »

Par : Daniel TSHIBANGU N'SENDULA

Mémoire présenté et défendu en vue de l'obtention du grade de Licencié en sciences économiques et de gestion.

Option : Gestion Informatique

Directeur : Osée MUHINDO MASIVI, CT Co-directeur : MUMBERE MUYISA, Ass.

ANNEE ACADEMIQUE: 2010-2011

II

EPIGRAPHE

« Les échecs des projets informatiques de migration ne se sont pas seulement dus à des problèmes informatiques. Ces problèmes peuvent être, entre autres, dus à la mauvaise formation des usagers du système ou aux changements inadéquats apportés aux processus d'affaires de l'organisation ou encore à l'obsolescence du système en place qui ne répond plus aux besoins. »

ERIC DARRAS

iii

DEDICACE

A vous mes parents RSB TSHIDINGI MUKENGESHAY et RSB KABANGA WA KASONGA pour votre éducation et croissance dans la vérité ;

A vous Mon oncle Guillaume MULENGA et tante Alphonsine KENDA, pour votre soutient combien inégalable ;

A la famille S.S. KADIMA

A vous ma meilleure amie AISHA RACHEL et notre progéniture ;

Et à vous tous qui nous sont très chers ;

Nous dédions ce travail

iv

REMERCIEMENTS

Après des années de dur labeur, nous sommes arrivés au terme de nos attentes et nous avons produit le travail que voici et qui a connu l'assistance de plus d'une personne. A Dieu le Père qui engendre par la parole de sa grâce envers nous.

Nous tenons à remercier sincèrement le CT Osée MASIVI, Directeur de ce modeste travail, de son attention et intérêt accordé à notre projet malgré ses multiples occupations bien qu'éloigné de nous. Qu'il trouve ici notre profonde gratitude. De même que l'Assistant MUMBERE MUYISA co-directeur.

Nos remerciements à toutes les autorités administratives ainsi que le corps professoral de l'Université Adventiste de Lukanga, de leur encadrement tant moral, intellectuel que spirituel durant les cinq années d'ensemble.

Nous ne saurons remercier les familles Rsb TSHIBANGU WALELU, SAFARI UWASE, TSHIABANYENGELE MUSANKISHI, MBUYI WA KASONGO, KABUNVU BWENDE, KABEYA TSHIPUIDISHI, MBUYI MUHAMED, MPOYI NFUAMBA, BWAYE N'KULI ; BALEDI TSHIBADIGENDA, AMIR GULZAR, Norbert VAGHENI, Maurice MAHAMBA, Jean Marie TSANGAMUSA, ANIFA NOTI, MUHAMED MBUYI & Brigitte SAFI, Anaclet MPONGO et Mario SENGHOMA.

Egalement à mes frères Laddy LUNGONZO, Simon MUYA, TUDJUNDILE KASONGO, et KASONGO MWANA, MAMPUYA KASONGO, Bernard KALUBI, Abdallah SAID, Benjamin KODJO, MOHAMED SAMATAR et mes soeurs KAPINGA KABWE, BUSAMBI BWA NZAMBI, Chantal NGONDO, Anna MULENGA, MUJINGA MOYO WANYI, Clémentine KASONGO, Edith NYOTA, Joël TSANGAMUSA, RAILA MARIAM, SIFA MUTHAKA et Tuzo KYALENGA.

Nos amis AISHA RACHEL, SALAMA SABUNI, Luc TUYISABE, Francis MASKINI, Agnès THUMBA, Janet MUREKATETE, Etienne AKONKWA, Yves KISONI, Janvier IBAMBI, Trésor KASOLENE, Joyeux MUHINDO, Osée KYAVU, Médiane SIVIRI et SESENE MWENZE. Plus particulièrement à nos compagnons de lutte M. FADHILI, K. NZALAMINGI, K. MALIRO, M. MUYISA(GB), Félix NDAYAMBAJE, C. MATANDA, M. MBOKANI, M. BABWINE, K. KITAHERUKA, M. SIVIKA, M. MAMBANI, L. DRAJIRO, K. LWANZO, et à tous les membres du Groupe d'Analystes et Chercheurs en Informatique.

Et à tous ceux qui de près ou de loin, nous ont fortement aidés.

Nous témoignons nos gratitudes.

V

SIGLES ET ABREVIATIONS

BD : Base de données

GL : Génie Logiciel

IAS : International accounting standards

IASB : International Accounting Standards Board

IEC : l'Intelligence Economique et Concurrentielle

IFRS : International Financial Reporting Standards

LL : Logiciel Libre

LP : Logiciel Propriétaire

MERISE : Méthode d'Etude et de Réalisation en Informatique pour Système

d'Entreprise

MOA : Maître d'ouvrage

MOE : Maître d'oeuvre

Ms : Microsoft

NTI : Nouvelles Technologies de l'Information

OHADA : Organisation pour l'Harmonisation en Afrique de Droits des Affaires

PME : Petites et Moyennes Entreprises

SGBD : Système de Gestion de Base de Données

SI : Système d'Information

SYSCOHADA : Système Comptable Ohada

TFC : Travail de Fin de Cycle

TIC : Technologies de l'Information et de Communication

Win : Windows

vi

LISTE DES FIGURES

Figure 1 . Représentation graphique d'une approche fonctionnelle 15

Figure 2: MCD CSCompta 28

Figure 3: MCD Gestion de Stocks TsangCom 30

Figure 4: Modèle de Classe Gestion Commerciale 30

Figure 5. Diagramme d'activité de la gestion de stock 37

Figure 6. Diagramme d'activité de la gestion de paie 38

Figure 7. Diagramme d'activité de la gestion comptable 39

Figure 8. Diagramme de contexte de l'application 42

Figure 9. Diagramme de cas d'utilisation de la gestion de stock 44

Figure 10. Diagramme de cas d'utilisation la de Gestion de Paie 45

Figure 11. Diagramme de cas d'utilisation de la Gestion Comptable 46

Figure 12. Diagramme de séquence pour le cas d'utilisation Authentifier 49

Figure 13. Diagramme de séquence pour le cas d'utilisation Ajout produit 49

Figure 14. Diagramme de séquence pour le cas d'utilisation gérer un bon de commande 50

Figure 15. Diagramme de séquence pour le cas d'utilisation Encaisser 51

Figure 16.Diagramme de classes Gestion de Stocks 52

Figure 17. Diagramme de séquence pour le cas d'utilisation Payer employé 53

Figure 18.Diagramme de classes Gestion de Paie 54

Figure 19. Digramme de Séquence Gestion Comptable 56

Figure 20.Diagramme de classes Gestion Comptable 57

Figure 21 . Formulaire de connexion à l'application pour le cas d'utilisation « authentification » 63

Figure 22.Capture d'écran du résultat d'ajout d'un utilisateur 64

Figure 23 . Capture d'écran du résultat de l'application de l'impression d'une facture de vente 65

Figure 24.Capture d'écran du résultat de l'application du cas d'utilisation « imputer un compte » 66

LISTE DE TABLEAUX

Tableau 1. tableau des messages en interaction 41

Tableau 2.Données test pour le cas d'utilisation « ajouter un utilisateur » 64

Tableau 3 . Données test pour le cas d'utilisation « éditer une facture de ventes » 65

Tableau 4.Données Test du cas d'utilisation « imputer un compte » 66

Tableau 5 . Données test du cas d'utilisation « Ajout d'un nouvel article » 67

Tableau 6. Capture d'écran du résultat de l'application du cas d'utilisation « Ajouter un nouvel

article » 67

VII

TABLE DE MATIERES

EPIGRAPHE ii

DEDICACE iii

REMERCIEMENTS iv

SIGLES ET ABREVIATIONS v

LISTE DES FIGURES vi

LISTE DE TABLEAUX vi

ABSTRACT xi

INTRODUCTION 1

1. PROBLEMATIQUE 1

2. HYPOTHESE 3

3. OBJECTIF DU TRAVAIL 3

4. INTERET ET CHOIX DU TRAVAIL 3

5. METHODES ET TECHNIQUES UTILISEES 4

6. DELIMITATION DU SUJET 4

7. SUBDIVISION DU TRAVAIL 4

CHAPITRE I : PROBLEMATIQUE DU GENIE LOGICIEL ET LE SYSTEME COMPTABLE OHADA 5

I.1. LE GENIE LOGICIEL 5

I.1.1 Les logiciels 5

I.1.2. Le génie logiciel 6

I.1.3. Les principes 6

I.1.4 Notion de qualité pour un logiciel 9

I.2. MODELISATION, CYCLES DE VIE ET METHODES 10

I.2.1 Pourquoi et comment modéliser ? 10

I.2.2 Le cycle de vie d'un logiciel 12

I.3 De la programmation structurée à l'approche Orientée Objet 13

VIII

1.3.1 Méthodes fonctionnelles ou structurées 15

II.2. NORMALISATION COMPTABLE 17

II.2.1. La notion de norme 17

II.3. L'ELABORATION DES NORMES 17

II.3.1. L'élaboration des normes internationales 17

II.4 SYSTEME COMPTABLE OHADA 18

II.4.1. Aperçu Historique 18

II.4 .2. L'adhésion de la RDC à l'OHADA 22

II.5. L'INFORMATISATION DE LA COMPTABILITE 23

II.5.1. Nécessités et enjeux de l'informatisation de la comptabilité 23

II. 6. L'IMPACT DE L'INFORMATISATION SUR LE TRAITEMENT DE L'INFORMATION

COMPTABLE 23

II.6.1.. Les caractéristiques fonctionnelles des logiciels adaptés à la gestion comptable 24

CHAPITRE II : LES ETUDES PREALABLES ET DETAILLEES 25

II.0. REVUE DE LITTERATURE 25

II.1. DEFINITION DES OBJECTIFS : 27

II.2. ANALYSE DES BESOINS ET FAISABILITE : 27

II.2.1. Analyse de l'existant 27

II.2.1.1. Formalisation informatique de la comptabilité hospitalière en RDC, cas de Centres de

Santé 28

II.2.1.2. Modélisation d'un système d'information informatisé et la conception d'une base de

données de gestion du stock des Ets Tsang 29

II.2.1.3. Logiciel de Gestion Commerciale 30

II.3. OPPORTUNITE DU PROJET 31

II.4. FAISABILITE DU PROJET 31

CHAPITRE III : CONCEPTION DE SOLUTIONS 34

III.1. SPECIFICATIONS OU CONCEPTION GENERALE : 34

ix

III.1.0. Généralités sur le Diagramme de cas d'utilisation 34

III.1.1. Contexte du système 35

III.1.2. Diagramme du contexte 40

III.1.3. Diagramme de cas d'utilisation 42

III.2. CONCEPTION DETAILLEE : 47

III.2.1. Diagrammes de Classes Gestion de Stock 47

III.2.2. Diagramme de Classes Gestion Paie 53

III.2.3. Diagramme de Classes Gestion Comptable 55

Chapitre IV : REALISATION DE LA SOLUTION 58

IV.1. IMPLEMENTATION DE LA SOLUTION 58

IV.1.1. Environnement de développement de l'application 58

IV.1.2.Implémentation de la base de données 60

IV.2. TEST DE L'APPLICATION 61

IV.2.1. Configuration matérielle requise 61

IV.2.2. Tests unitaires 63

IV.3. QUALIFICATION 68

IV.4. DOCUMENTATION 68

IV.5.1. Documentation orientée Programmeurs 68

IV.5.2. Documentation orientée Utilisateurs 68

CONCLUSION GENERALE 70

BIBLIOGRAPHIE 72

X

Résumé

Dans l'économie de marché qui est la nôtre, la bonne santé des entreprises régit celle du pays. Il est important qu'elles soient efficaces et rentables. Pour réduire leurs coûts, elles se sont massivement équipées de l'outil informatique depuis plusieurs décennies : elles ont ainsi pu notamment gagner du temps et améliorer leur gestion. Les plus petites structures ont suivi le mouvement plus récemment.

Un certain équilibre entre les constructeurs de matériel informatique, les éditeurs de logiciels et les utilisateurs semble s'être trouvé. En effet, les quasimonopoles d'un nombre croissant d'éditeurs -chacun dans son ou ses domaines imposent une certaine homogénéité aux utilisateurs. Mais en y regardant de plus près, on constate qu'une nouvelle famille de logiciels gagne sensiblement des parts d'utilisateurs : les logiciels dits « libres ».

Les échanges de logiciels entre fabricants et groupes d'utilisateurs sont la règle. Chacun y trouve son compte : les utilisateurs bénéficient gratuitement des applications et, en cas de dysfonctionnements, ils corrigent les bogues et renvoient les améliorations aux fabricants. Cette opération est rendue possible car n'importe qui peut avoir accès au code source des programmes.

De l'autre bout, il est important de prouver que l'utilisation de principes du génie logiciel a fait défaut dans le chef de fabricants des logiciels et la crise du logiciel s'en est suivi.

En ce qui nous concerne, le système comptable congolais trop longtemps resté statique n'a pas encouragé le développement de PME, base de l'essor économique d'un pays. Cependant, la RDC lorsqu'elle a voulu adhérer au nouveau système qui est le SYSCHODA et consciente des insuffisances de son système amène toutes les entreprises à migrer vers la nouvelle loi comptable régissent les affaires en Afrique ; et c'est sur ce point que les besoins d'informatisation se fait ressentir en ne voulant pas faire une tabula rasa des anciennes applications mais aussi les concevoir dans le processus de migration en tenant compte de techniques et principes du génie logiciel.

C'est modeste travail s'est assigné le défi à relever en concevant un logiciel de gestion de stock commercial intégré à la comptabilité en respectant les normes du SYSCHOHADA et du génie logiciel et le plaçant dans la catégorie de logiciels libres c'est-à-dire comme dit ci haut que les utilisateurs ont le privilège de modifier les codes sources et de personnalises l'application.

xi

ABSTRACT

In economic market environment which is shared by many people of a country depends on one's companies. The later need to be efficient and profitable. To minimize operating costs; many of them have resorted to Information Technology equipments long years ago. The improving of management helped to gain on time. Very recently, small business followed the charging environment.

A certain balance between computer equipment designers, editors of software and end users has been met. A bind of monopoly of programmer -editors led users to a certain homogeneous. However a new range of software is being launched and users have access to programs named free.

Soft ware's traits between programmers and users get free application programs and if it happen a malfunctioning ,the user can debug and send buck the improvements to the designer it has become possible engine to access to sources codes of programs. Only expert and passionate student to information technology go deep in sophisticated software.

On the other hand, software designer not care much in using software engineering principles. This situation led to software engineering crisis

Our study tend to look at the DRC accounting system which has been static and likewise hinders the development of the small business. Witch are fade mental for the booming of economy in a country.

DRC wishing to join SYSCHOHADA accounting system should be aware of this poor standards, when he takes all the companies to migrate to the new accounting system which regulate now business in Africa. This situation makes a need to use information technology in companies without neglecting the former accounting system. The process of migrating must take in account techniques and principles of software engineering. This study comes to feel the challenge brought in by the new accounting system SYSCHOHADA, by designers a software engineering in a group of fool software. This will easy the users to modify sources code and adjust the program to their needs.

1

INTRODUCTION

1. PROBLEMATIQUE

L'informatisation est parmi les phénomènes les plus importants de notre époque. Elle s'immisce maintenant dans la plupart des objets de la vie courante et ce, que ce soit dans l'objet proprement dit, ou bien dans le processus de conception ou de fabrication de cet objet.

De plus, la baisse continuelle des prix du matériel informatique causée par les innovations technologiques, rend chaque jour plus important le rôle joué par l'informatique dans les sociétés industrialisées...

Chaque année, des dizaines de milliers de logiciels interactifs sont développés dans les entreprises. Dans le meilleur des cas, l'équipe de développement se base sur une méthode rigoureuse de développement issue du Génie Logiciel.

Cependant, il est fréquent de constater que les systèmes interactifs posent en général de nombreux problèmes d'utilisabilité, ne répondent pas toujours aux besoins des utilisateurs, sont mal adaptés à l'organisation du travail, etc. C'est en ce sens que d'après le cabinet de conseil en technologies de l'information Standish Group International, les pannes causées par des problèmes de logiciel ont coûté l'an dernier aux entreprises du monde entier environ 175 milliards de dollars, soit deux fois plus au moins qu'il y a 2 ans. (Audibert, 2006). Il est important de relever que ces problèmes sont liés à la complexité croissante des systèmes informatiques : difficulté de développement, aux risques de retards et de surcoûts conduisant aux risques de défaillances dues à des erreurs de conception, ...

En amont, l'Organisation pour l'Harmonisation en Afrique du Droit des Affaires (OHADA) organise l'unification du droit des affaires et le règlement des litiges par une juridiction supranationale ainsi que la promotion de l'arbitrage pour favoriser l'institution d'une Communauté Economique Africaine, promouvoir l'unité africaine pour développer l'activité économique, garantir la sécurité juridique et judiciaire au sein de cette communauté.

Si, selon Madimba Kadima Nzuji (Kinshasa, 4 février 2005), les petites et moyennes entreprises (P.M.E.) constituent le poumon de l'économie d'un pays, jouent un rôle macroéconomique de premier plan, source de dynamisme et de flexibilité, alors tout pays qui souhaite se développer économiquement doit encadrer et favoriser la création d'entreprise et donner le goût

2

d'entreprendre à ses citoyens. Or, le droit congolais des affaires par le biais du Plan Comptable Général Congolais de 1976 n'encourage pas cette vision et enchaîne les PME au détriment du pouvoir public.

Il est évident de constater qu'au moment où notre pays se pacifie et reprend le chemin de la croissance économique, la sécurité juridique et judiciaire reste l'un des secours possible a travers notamment l'adhésion a l'OHADA. Cette adhésion contribuera à améliorer le climat des affaires et à renforcer l'attractivité de la RDC, avec comme effets d'entraînement la compétitivité des entreprises, la croissance économique et le développement. La RDC figure à la queue des statistiques sur le développement humain et est souvent présenté comme un pays à risque. Prendre le pari de l'Ohada n'apportera pas une solution totale, mais y contribuera sensiblement. (MAKELA, 2005).

En outre, le système comptable Ohada, offre une large facilité à pouvoir informatiser nos petites et moyennes entreprises de part sa réglementation. Toutefois, l'adhésion à ce système n'engendre automatiquement les retombées susmentionnées. Et dans le cas de l'informatisation, des préalables existent pour espérer à la croissance. Et du fait que le SYSCHOHADA a une autre manière de traitement du stock commercial par rapport au PCGC en ce sens que les écritures sont doublées en SYSCHOHADA passant par le compte de variation de stock. Et c'est ici que se focalise notre projet d'informatisation.

En effet, le discours et l'action actuels en faveur des Logiciel Libre(LL) en Afrique restent encore insuffisants et évasifs pour articuler ceux-ci au développement et doivent, pour atteindre cet objectif, graviter autour des spécificités des LL, c'est-à-dire autour de la disponibilité du code source, et de l'alternative économique et éthique que ce code recèle. Dans la mesure où l'enjeu est l'appropriation du code source, le vrai problème pour l'Afrique devient la mise en place de l'industrie logicielle destinée à tirer parti de l'ouverture de ce code, la cohabitation têtue avec des logiciels propriétaires (LP) et la résolution des problèmes de migration des LP vers des LL. Militer pour la solution des LL en Afrique sans militer pour l'industrie logicielle, bénéficiaire de l'ouverture du code source et "multiplicatrice" de l'innovation logicielle, c'est vouloir se baigner sans avoir contact avec l'eau. (Ntambue-Tshimbulu, 2003).

Il se laisse transparaître de ce qui précède que les règles de l'industrie informatique regroupées dans ce que nous appelons communément « Génie Logiciel » doivent être mise en contribution pour l'intégration de l'OHADA dans l'informatisation des services du tissu économique

3

congolais notamment la comptabilité. Mais la question qui se laisse posée et à la quelle notre travail se propose de répondre est « quelles règles appliquer pour intégrer en douceur l'OHADA dans les systèmes informatiques existants ? ».

Que gagnons-nous en intégrant les principes du génie logiciel (impact) dans la conception et développement d'un logiciel et dans le cas échéant ce que nous perdons en le calquant sur le modèle du Système Comptable Ohada ? est la grande question qui se laisse poser.

2. HYPOTHESE

Notre mot anticipatif sur cette obsession majeure serait que : l'intégration de principes du génie logiciel dans la conception et développement du logiciel sur le modèle du SYSCOHADA aura un effet très positif sur l'efficacité et l'efficience du dit logiciel, de le réaliser dans les délais prévus, tout en satisfaisant le cahier des charges et qu'autrement ce logiciel s'inscrira dans la catégorie de logiciel obsolètes !

3. OBJECTIF DU TRAVAIL

Notre objectif général est de prouver qu'a travers les principes du génie logiciel, nous pouvons éviter le tabula rasa et que les logiciels existant peuvent migrer vers des systèmes plus complexes en moindre cout.

Il sera question pratiquement de choisir et appliquer les règles du Génie Logiciel aux logiciels de gestion de stock existant en comptabilité générale pour mettre en place un logiciel de gestion de stock respectant les normes comptables du SYSCOHADA.

4. INTERET ET CHOIX DU TRAVAIL

L'intérêt majeur de notre sujet est d'aider les chefs de projets à faire migrer les logiciels actuellement adaptés au PCGC vers le SYSOHADA en :

? en produisant des logiciels adaptés aux besoins

? en réduisant les coûts de maintenance

? en rendant les logiciels productifs dans un délai raisonnable.

Ce faisant ainsi, nous serons entrain de parfaire notre connaissance théorique à la pratique et aussi en aidant les développeurs à avoir une idée sur l'intégration de principes du génie logiciel dans leur développement de logiciel dans un Système Comptable quelconque.

4

5. METHODES ET TECHNIQUES UTILISEES

L'expérience a montré que l'absence de méthode conduisait à des catastrophes dès lors que

les logiciels applicatifs atteignent une certaine ampleur. Soit le projet n'aboutit pas, soit le logiciel se révèle non maintenable, soit il ne répond pas aux besoins (Marcel SOBRMAN, 1992).

Il nous sera nécessaire de prendre les programmes de gestion existants et les compiler dans un seul programme tout en le laissant ouvert afin permettre l'ajout de certains modules selon le besoin des utilisateurs ; d'où il s'inscrit dans le domaine du logiciel libre. Nous utiliserons une simulation d'un travail en équipe de génie pour arriver à cette fin.

Pour y arriver, nous nous servirons des principes, techniques et outils suivants :

- La technique documentaire nous aidera à prévoir d'une manière un peu large des
éléments de doctrine ayant trait à notre objet d'étude.

- Le langage de modélisation appelée « UML » pour Unified Modeling Language
pour l'analyse de besoins et la conception de solutions.

- Le langage de programmation C# 2008 pour mettre en place l'application

6. DELIMITATION DU SUJET

Pour ne pas risquer de se noyer dans l'océan qui est la comptabilité, nous essayerons de nous

intéresser sur la Comptabilité Générale dont les aspects de la comptabilité financière c'est-à-dire l'enregistrement des transactions passant par la tenue de livres aboutissant par le compte de résultat et le calcul d'amortissement pour les immobilisations feront mention dans notre travail.

7. SUBDIVISION DU TRAVAIL

Hormis l'introduction et la conclusion, ce travail se subdivise en quatre chapitres :

- Le premier chapitre concerne les généralités sur le génie logiciel et le système comptable Ohada ; - Le second chapitre concerne les études préalables ;

- Le troisième est la conception des solutions

- et la réalisation constituera le dernier.

5

CHAPITRE I : PROBLEMATIQUE DU GENIE LOGICIEL ET LE SYSTEME
COMPTABLE OHADA

I.1. LE GENIE LOGICIEL

I.1.1 Les logiciels

Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique d'assurer une tâche ou une fonction en particulier (exemple : logiciel de comptabilité, logiciel de gestion des prêts).

Les logiciels, suivant leur taille, peuvent être développés par une personne seule, une petite équipe, ou un ensemble d'équipes coordonnées. Le développement de grands logiciels par de grandes équipes pose d'importants problèmes de conception et de coordination. Or, le développement d'un logiciel est une phase absolument cruciale qui monopolise l'essentiel du coût d'un produit et conditionne sa réussite et sa pérennité.

En 1995, une étude du Standish Group dressait un tableau accablant de la conduite des projets informatiques. Reposant sur un échantillon représentatif de 365 entreprises, totalisant 8 380 applications, cette étude établissait que :

? 16,2% seulement des projets étaient conformes aux prévisions initiales,

? 52,7% avaient subi des dépassements en coût et délai d'un facteur 2 à 3 avec diminution du nombre des fonctions offertes,

? 31,1% ont été purement abandonnés durant leur développement.

Pour les grandes entreprises (qui lancent proportionnellement davantage de gros projets), le taux de succès est de 9% seulement, 37% des projets sont arrêtés en cours de réalisation, 50% aboutissent hors délai et hors budget.

L'examen des causes de succès et d'échec est instructif : la plupart des échecs proviennent non de l'informatique, mais de la maîtrise d'ouvrage (i.e. le client). Pour ces raisons, le développement de logiciels dans un contexte professionnel suit souvent des règles strictes encadrant la conception et permettant le travail en groupe et la maintenance du code. Ainsi, une nouvelle discipline est née : le génie logiciel.

Le niveau maximum de rigueur est la formalité, c'est à dire le cas où les descriptions et les validations s'appuient sur des notations et lois mathématiques. Il n'est pas possible d'être formel tout

6

I.1.2. Le génie logiciel

Le génie logiciel est un domaine de recherche qui a été défini (fait rare) du 7 au 11 octobre 1968, à Garmisch-Partenkirchen, sous le parrainage de l'OTAN. Il a pour objectif de répondre à un problème qui s'énonçait en deux constatations : d'une part le logiciel n'était pas fiable, d'autre part, il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leur cahier des charges.

L'objectif du génie logiciel est d'optimiser le coût de développement du logiciel. L'importance d'une approche méthodologique s'est imposée à la suite de la crise de l'industrie du logiciel à la fin des années 1970.

Il est à noter que l'utilisation de certains principes dans la conception du logiciel s'avère indispensable.

I.1.3. Les principes

Dans cette section nous listons sept principes fondamentaux (proposés par Carlo Ghezzi) dont nous essayerons d'appliquer dans le présent travail:

· rigueur,

· séparation des problèmes (« separation of concerns »),

· modularité,

· abstraction,

· anticipation du changement,

· généricité,

· construction incrémentale.

I.1.3.1. Rigueur

La production de logiciel est une activité créative, mais qui doit se conduire avec une certaine rigueur. Certains opposent parfois créativité et rigueur. Il n'y a pas contradiction : par exemple, le résultat d'une activité de création pure peut être évalué rigoureusement, avec des critères précis.

7

le temps : il faut bien construire la première description formelle à partir de connaissances non formalisées ! Mais dans certaines circonstances les techniques formelles sont utiles.

I.1.3.2. "Séparation des problèmes"

C'est une règle de bons sens qui consiste à considérer séparément différents aspects d'un problème afin d'en maîtriser la complexité. C'est un aspect de la stratégie générale du « diviser pour régner ».

Elle prend une multitude de formes :

? séparation dans le temps (les différents aspects sont abordés successivement), avec la notion de cycle de vie du logiciel que nous brosserons dans la suite,

? séparation des qualités que l'on cherche à optimiser à un stade donné (ex : assurer la correction avant de se préoccuper de l'efficacité),

? séparations des `vues' que l'on peut avoir d'un système (ex : se concentrer sur l'aspect flots de données' avant de considérer l'aspect ordonnancement des opérations ou flot de contrôle'),

? séparation du système en parties (un noyau, des extensions, ...),

? etc.

Les méthodes aident à organiser le travail en guidant dans la séparation et l'ordonnancement des questions à traiter.

I.1.3.3. Modularité

Un système est modulaire s'il est composé de sous-systèmes plus simples, ou modules. La modularité est une propriété importante de tous les procédés et produits industriels (cf. l'industrie automobile ou le produit et le procédé sont très structurés et modulaires).

La modularité permet de considérer séparément le contenu du module et les relations entre modules (ce qui rejoint l'idée de séparation des questions). Elle facilite également la réutilisation de composants biens délimités.

Un bon découpage modulaire se caractérise par une forte cohésion interne des modules (ex : fonctionnelle, temporelle, logique, ...) et un faible couplage entre les modules (relations inter modulaires en nombre limité et clairement décrites).

Toute l'évolution des langages de programmation vise à rendre plus facile une programmation modulaire, appelée aujourd'hui programmation par composants'.

8

I.1.3.4. Abstraction

L'abstraction consiste à ne considérer que les aspects jugés importants d'un système à un moment donné, en faisant abstraction des autres aspects (c'est encore un exemple de séparation des problèmes).

Une même réalité peut souvent être décrite à différents niveaux d'abstraction. Par exemple, un circuit électronique peut être décrit par un modèle mathématique très abstrait (équation logique), ou par un assemblage de composants logiques qui font abstraction des détails de réalisation (circuit logique), ou par un plan physique de composants réels au sein d'un circuit intégré. L'abstraction permet une meilleure maîtrise de la complexité.

I.1.3.5. Anticipation du changement

La caractéristique essentielle du logiciel, par rapport à d'autres produits, est qu'il est presque toujours soumis à des changements continuels (corrections d'imperfections et évolutions en fonctions des besoins qui changent).

Ceci requiert des efforts particuliers pour prévoir, faciliter et gérer ces évolutions inévitables. Il faut par exemple :

· faire en sorte que les changements soient les plus localisés possibles (bonne modularité),

· être capable de gérer les multiples versions des modules et configurations des versions des modules, constituant des versions du produit complet.

I.1.3.6. Généricité

Il est parfois avantageux de remplacer la résolution d'un problème spécifique par la résolution d'un problème plus général. Cette solution générique (paramétrable ou adaptable) pourra être réutilisée plus facilement.

Exemple : plutôt que d'écrire une identification spécifique à un écran particulier, écrire (ou réutiliser) un module générique d'authentification (saisie d'une identification - éventuellement dans une liste - et éventuellement d'un mot de passe).

I.1.3.7. Construction incrémentale

Un procédé incrémental atteint son but par étapes en s'en approchant de plus en plus ; chaque résultat est construit en étendant le précédent.

9

On peut par exemple réaliser d'abord un noyau des fonctions essentielles et ajouter progressivement les aspects plus secondaires. Ou encore, construire une série de prototypes simulant' plus ou moins complètement le système envisagé.

Ces principes sont très abstraits et ne sont pas utilisables directement. Mais ils font partie du vocabulaire de base du génie logiciel. Ces principes ont un impact réel sur beaucoup d'aspects et constituent le type de connaissance le plus stable, dans un domaine où les outils, les méthodes et les techniques évoluent très vite.

I.1.4 Notion de qualité pour un logiciel

En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l'application et des outils utilisés. Parmi ces derniers nous pouvons citer :

Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications.

Fiabilité ou robustesse : aptitude d'un produit logiciel à fonctionner dans des conditions anormales. Extensibilité (maintenance) : facilité avec laquelle un logiciel se prête à sa maintenance, c'est-à-dire à une modification ou à une extension des fonctions qui lui sont demandées.

Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications.

Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels.

Efficacité : Utilisation optimales des ressources matérielles.

Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels.

Vérifiabilité : facilité de préparation des procédures de test.

Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés. Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

Ces facteurs sont parfois contradictoires, le choix des compromis doit s'effectuer en fonction du contexte.

10

I.2. MODELISATION, CYCLES DE VIE ET METHODES

I.2.1 Pourquoi et comment modéliser ?

Qu'est-ce qu'un modèle ?

Un modèle est une représentation abstraite et simplifiée (i.e. qui exclut certains détails), d'une entité (phénomène, processus, système, etc.) du monde réel en vue de le décrire, de l'expliquer ou de le prévoir. Modèle est synonyme de théorie, mais avec une connotation pratique : un modèle, c'est une théorie orientée vers l'action qu'elle doit servir.

Concrètement, un modèle permet de réduire la complexité d'un phénomène en éliminant les détails qui n'influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du phénomène modélisé. Les limites du phénomène modélisé dépendant des objectifs du modèle.

Pourquoi modéliser ?

Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen de maîtriser sa complexité et d'assurer sa cohérence. Un modèle est un langage commun, précis, qui est connu par tous les membres de l'équipe et il est donc, à ce titre, un vecteur privilégié pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune aux différentes parties prenantes (notamment entre la maîtrise d'ouvrage et la maîtrise d'oeuvre informatique) et précise d'un problème donné.

Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d'automatiser certaines d'entre elles. C'est également un facteur de réduction des coûts et des délais. Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) voire des aller-retours entre le code et le modèle sans perte d'information. Le modèle est enfin indispensable pour assurer un bon niveau de qualité et une maintenance efficace. En effet, une fois mise en production, l'application va devoir être maintenue, probablement par une autre équipe et, qui plus est, pas nécessairement de la même société que celle ayant créée l'application.

Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non-triviaux sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n'est pas la même.

11

Qui doit modéliser ?

La modélisation est souvent faite par la maîtrise d'oeuvre informatique (MOE). C'est malencontreux, car les priorités de la MOE résident dans le fonctionnement de la plate-forme informatique et non dans les processus de l'entreprise.

Il est préférable que la modélisation soit réalisée par la maîtrise d'ouvrage (MOA) de sorte que le métier soit maître de ses propres concepts. La MOE doit intervenir dans le modèle lorsque, après avoir défini les concepts du métier, on doit introduire les contraintes propres à la plate-forme informatique.

Il est vrai que certains métiers, dont les priorités sont opérationnelles, ne disposent pas toujours de la capacité d'abstraction et de la rigueur conceptuelle nécessaires à la formalisation. La professionnalisation de la MOA a pour but de les doter de ces compétences. Cette professionnalisation réside essentiellement dans l'aptitude à modéliser le système d'information du métier : le maître mot est modélisation. Lorsque le modèle du système d'information est de bonne qualité, sobre, clair, stable, la maîtrise d'oeuvre peut travailler dans de bonnes conditions. Lorsque cette professionnalisation a lieu, elle modifie les rapports avec l'informatique et déplace la frontière des responsabilités, ce qui contrarie parfois les informaticiens dans un premier temps, avant qu'ils n'en voient apparaître les bénéfices.

Maîtrise d'ouvrage et maîtrise d'oeuvre

Maître d'ouvrage (MOA) :

Le MOA est une personne morale (entreprise, direction etc.), une entité de l'organisation. Ce n'est jamais une personne.

Maître d'oeuvre (MOE) :

Le MOE est une personne morale (entreprise, direction etc.) garante de la bonne réalisation technique des solutions. Il a, lors de la conception du SI, un devoir de conseil vis-à-vis du MOA, car le SI doit tirer le meilleur parti des possibilités techniques.

Le MOA est client du MOE à qui il passe commande d'un produit nécessaire à son activité. Le MOE fournit ce produit ; soit il le réalise lui-même, soit il passe commande à un ou plusieurs fournisseurs (« entreprises ») qui élaborent le produit sous sa direction.

La relation MOA et MOE est définie par un contrat qui précise leurs engagements mutuels.

12

Lorsque le produit est compliqué, il peut être nécessaire de faire appel à plusieurs fournisseurs. Le MOE assure leur coordination ; il veille à la cohérence des fournitures et à leur compatibilité. Il coordonne l'action des fournisseurs en contrôlant la qualité technique, en assurant le respect des délais fixés par le MOA et en minimisant les risques.

Le MOE est responsable de la qualité technique de la solution. Il doit, avant toute livraison au MOA, procéder aux vérifications nécessaires (« recette usine »).

I.2.2 Le cycle de vie d'un logiciel

Le cycle de vie d'un logiciel (en anglais software lifecycle), désigne toutes les étapes du développement d'un logiciel, de sa conception à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons (repères) intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en oeuvre.

L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.

Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes : Définition des objectifs :

Cette étape consiste à définir la finalité du projet et son inscription dans une stratégie globale. Analyse des besoins et faisabilité :

C'est-à-dire l'expression, le recueil et la formalisation des besoins du demandeur (le client) et de l'ensemble des contraintes, puis l'estimation de la faisabilité de ces besoins.

Spécifications ou conception générale :

Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel.

Conception détaillée :

Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.

Codage (Implémentation ou programmation) :

C'est la traduction dans un langage de programmation des fonctionnalités définies lors de phases de conception.

13

Tests unitaires :

Ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est

implémenté conformément aux spécifications.

Intégration :

L'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Elle

fait l'objet de tests d'intégration consignés dans un document.

Qualification (ou recette) :

C'est-à-dire la vérification de la conformité du logiciel aux spécifications initiales.

Documentation :

Elle vise à produire les informations nécessaires pour l'utilisation du logiciel et pour des

développements ultérieurs.

Mise en production :

C'est le déploiement sur site du logiciel.

Maintenance :

Elle comprend toutes les actions correctives (maintenance corrective) et évolutives

(maintenance évolutive) sur le logiciel.

La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix

d'un modèle de cycle de vie entre le client et l'équipe de développement. Le cycle de vie permet de

prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains.

I.3 De la programmation structurée à l'approche Orientée Objet

Une méthode :

- propose une démarche, distinguant les étapes du développement dans le cycle de vue du

logiciel et exploitant au mieux les principes fondamentaux : modularité, réduction de la

complexité, réutilisation, abstraction, etc.,

- propose des formalismes (langages) et des types de documents (modèles), qui facilitent

la communication, l'organisation et la vérification,

Parmi les principaux objectifs des méthodes objets, on peut noter la volonté de :

? regrouper l'analyse des données et des traitements,

14

? établir un couplage explicite entre les concepts du monde réel et les composants exécutables (« réduire la distance sémantique entre le langage des concepteurs et celui des utilisateurs »), ? faciliter la réutilisation,

? simplifier les transformations entre le niveau conceptuel et l'implantation.

Ce langage commun s'appelle UML (Unified Modeling Language'). UML est une notation basée principalement sur les méthodes OOD (de Booch), OMT (de Rumbaugh) et OOSE (de Jacobson).

UML a été proposé afin de standardiser les produits du développement modèles, notations, diagrammes) sans standardiser le processus de développement. Il est en effet très difficile de standardiser le processus de développement qui dépend des personnes, des applications, des cultures, etc. UML se propose de créer un langage de modélisation utilisable à la fois par les humains (forme graphique) et les machines (syntaxe précise).

15

1.3.1 Méthodes fonctionnelles ou structurées



Figure 1 : Représentation graphique d'une approche fonctionnelle

16

Les méthodes fonctionnelles (également qualifiées de méthodes structurées) trouvent leur origine dans les langages procéduraux. Elles mettent en évidence les fonctions à assurer et proposent une approche hiérarchique descendante et modulaire.

L'approche fonctionnelle dissocie le problème de la représentation des données, du problème du traitement de ces données. Sur la figure 1.1, les données du problème sont représentées sur la gauche. Des flèches transversales matérialisent la manipulation de ces données par des sous-fonctions. Cet accès peut-être direct (c'est parfois le cas quand les données sont regroupées dans une base de données), ou peut être réalisé par le passage de paramètre depuis le programme principal.

La SADT (Structured Analysis Design Technique) est probablement la méthode d'analyse fonctionnelle et de gestion de projets la plus connue (méthode que nous utiliserons dans le cas de notre travail). Elle permet non seulement de décrire les tâches du projet et leurs interactions, mais aussi de décrire le système que le projet vise à étudier, créer ou modifier, en mettant notamment en évidence les parties qui constituent le système, la finalité et le fonctionnement de chacune, ainsi que les interfaces entre ces diverses parties. Le système ainsi modélisé n'est pas une simple collection d'éléments indépendants, mais une organisation structurée de ceux-ci dans une finalité précise.

17

II.2. NORMALISATION COMPTABLE

II.2.1. La notion de norme

Une norme est une règle à laquelle on se réfère.

Ainsi, la présentation des comptes sociaux (bilan, compte de résultat) est normalisée. Les intitulés des postes du bilan, la disposition des informations sont réglementés. Toutes les entreprises doivent respecter ces normes.

II.2.2. Nécessité et enjeux de la normalisation

La normalisation est apparue pour répondre à la nécessité d'exercer un contrôle économique et fiscal sur les entreprises.

(Par exemple, on impose à toutes les entreprises des règles de calcul du résultat fiscal afin de calculer l'impôt que les entreprises devront verser.)

La comptabilité a longtemps été limitée au contexte national. Chaque pays a ainsi mis en place ses propres normes comptables.

L'ouverture des frontières, le développement de la mondialisation imposent une harmonisation de ces normes afin de pouvoir :

? comparer les comptabilités de différentes entreprises sur un même secteur d'activité (dans l'espace) ;

? comparer les résultats des entreprises dans le temps ;

? faciliter la prise de décision (notamment des investisseurs).

La normalisation de la comptabilité financière présente donc un intérêt non seulement pour les investisseurs mais également pour tous les partenaires de l'entreprise (salariés, Etat, banques, clients, fournisseurs) qui peuvent grâce à ce langage commun renforcer leur confiance dans l'entreprise.

II.3. L'ELABORATION DES NORMES

II.3.1. L'élaboration des normes internationales

L'IASB (International Accounting Standards Board)

L'IASB pour fonction d'élaborer des normes comptables internationales afin d'harmoniser les règles et pratiques comptables.

Ces normes s'appelaient, avant 2001, des IAS (International accounting standards - Normes comptables internationales)

Depuis la réforme de l'IASB en 2001, ces normes s'appellent des IFRS (International

18

Financial

Reporting Standards - Normes d'information financière internationales). Les IFRS ne sont plus des normes de comptabilité mais des normes d'information financière

II.4 SYSTEME COMPTABLE OHADA

II.4.1. Aperçu Historique

Attendu que l'organisation interne et externe d'une entreprise nous apprend que toute entreprise se crée pour la survie et non pour tenter sa chance ou par hasard :

- La Société s'entend comme une mise en commun de deux ou plusieurs personnes, d'un capital pour une exploitation commerciale, industrielle ou de vente des services en vue de partager le résultat qui pourra en résulter.

- Quant à l'Entrepreneur, c'est toute personne qui engage son capital dans une activité commerciale, industrielle ou de vente des services en vue d'en tirer un profit mais avec comme risque de le perdre ou de gagner.

Nous constatons ensemble que l'ossature de nos deux définitions contient des éléments qui assurent que les entreprises puissent fonctionner normalement dans un cadre juridique et judiciaire bien protégé pour que l'intérêt de l'ensemble des parties soit préservé.

Ces éléments sont entre autres :

1. Le droit commercial général ;

2. Le droit des sociétés commerciales, et groupement d'intérêt économique ;

3. L'organisation des sûretés ;

4. Le droit de recouvrement des créances ;

5. Le droit des entreprises en difficulté, etc.

Tous ces éléments cités ci-dessus ont été élaborés sur mesure selon les besoins des colonisateurs de chaque pays africain. Ce qui a entraîné le fait que certains pays en Afrique, comme ailleurs dans d'autres parties du monde ont connu des retards dans leurs développements.

C'est pour cette raison que 30 ans après les Indépendances, les Ministres des Finances de la Zone Franc en Afrique, avaient constaté un ralentissement des investissements dans leurs régions. Ils l'avaient clairement et très justement attribué à la méfiance des opérateurs économiques. Ils avaient même pensé que cette méfiance pouvait avoir pour origine la trop grande variété des réglementations et des solutions de règlement des différends applicables au droit des affaires.

19

Poursuivant leur raisonnement, les ministres ont souhaité déterminer la cause réelle du phénomène qui a eu une conséquence négative directe et importante sur les programmes de développement économique dans chacun de leurs pays. Ils ont alors crée une « Mission de haut niveau » dont l'objet était d'établir un diagnostic des difficultés et de préconiser des remèdes.

Cette mission était confiée au Juge Président près la Cour Internationale de la Haye en la personne de Monsieur Keba Mbaye de nationalité Camerounaise.

Après avoir visité tous les pays africains concernés et pris contact avec les différentes autorités politiques, les différents dirigeants des entreprises, les acteurs de la vie professionnelle et les organisations nationales ayant une relation même apparemment lointaine avec la vie économique, les résultats de ces investigations ont conduit à une conclusion qui s'est résumée dans une expression assez souvent reprise depuis lors, à savoir que l'origine du mal n'était rien d'autre que « l'insécurité juridique et judiciaire » qui régnait à l'époque dans les pays. Elle était due au délabrement du tissu juridique et à caractère épars et inadapté des textes légués par nos anciennes métropoles face aux réalités économiques du monde moderne.

Le rapport de Monsieur Keba Mbaye avait intéressé bon nombre d'Etats africains à penser qu'il fallait un « nouveau droit commun au plus grand nombre de pays qui soit moderne et harmonisé » et qui serait interprété par « des magistrats bien préparés en matière de droit des affaires » et appliqué en dernier ressort par « une juridiction supranationale unique ».

Voilà comment a germé l'idée d'une organisation chargée d'harmoniser le droit des affaires en Afrique. Les chefs d'Etat, réunis en octobre 1992 à Libreville ont, sur le rapport du président Abdou Diouf du Sénégal, approuvé les conclusions de la Mission et les ont élargies à l'ensemble de l'Afrique, signant ainsi l'acte de naissance de l'Organisation pour l'Harmonisation en Afrique du Droit des Affaires, OHADA en sigle.

Présentement cette organisation compte en son sein seize Etats Africains comme membres, et notre pays la République Démocratique du Congo a confirmé son adhésion depuis l'an passé, cela sur la volonté expresse de notre Président, SE Joseph KABILA.

Par ailleurs, une récente analyse avait révélé que les règles actuelles applicables aux affaires sont éparses, par conséquent peu accessibles, parfois fragmentaires, voir lacunaires et bien souvent archaïques comme peuvent en témoigner :

- Le droit des sociétés par actions à responsabilité limitée, embryonnaire et obsolète,

20

- Le droit de la faillite, largement dépassé par la pensée juridique moderne qui privilégie autant que possible le sauvetage des entreprises en difficulté,

- Le droit des contrats commerciaux qui se réfugie souvent de manière hasardeuse derrière le droit civil des contrats usuels et spéciaux,

- Le droit commercial général qui ne réglemente même pas le bail commercial, - Le registre du commerce, insuffisamment organisé.

En outre, notre droit ignore encore diverses techniques juridiques répandues à travers le monde, entre autres :

- La société unipersonnelle, qui contribuerait à structurer le secteur informel congolais ;

- Le groupement d'intérêt économique,

- Le droit des sociétés, notamment pour la répression des abus des biens sociaux, par exemple,

- Les procédures d'alerte, visant à renforcer la prévention des risques dans les sociétés,

- L'optimisation du rôle et de l'autonomie des commissaires aux comptes,

- Le mécanisme de la lettre de garantie en droit des sûretés.

En RDCongo, le droit processuel des affaires s'illustre, par la pratique de jugements iniques, à cause de divers maux dont souffre l'appareil judiciaire congolais, entre autres l'absence de formation permanente et de spécialisation des magistrats, l'ignorance des procédures de recouvrement accéléré des créances et la stagnation des règles organisant les voies d'exécution, dont certains procédés comme la saisie-attribution par exemple.

D'où le souci de réformer notre droit des affaires.

Pour mémoire, l'OHADA a été instituée par le traité relatif à l'harmonisation du droit des affaires en Afrique, dit « Traité de Port-Louis », signé à Port-Louis le 17 Octobre 1993. Il est entré en vigueur en 1995. Le Sénégal est le pays dépositaire de ce Traité.

Le but de l'OHADA est de promouvoir l'émergence d'une communauté Economique Africaine, de renforcer la sécurité juridique et judiciaire pour favoriser le développement de l'Afrique et de contribuer à la consolidation de l'Unité Africaine. A cet effet, elle instaure un espace juridique commun par des règles unifiées et un espace judiciaire commun à travers une juridiction supranationale jouant le rôle d'une Cour Suprême.

21

Ses institutions sont :

- Le Conseil des Ministres, organe législatif qui vote les actes uniformes et qui siège au sein du pays assumant la présidence de l'Organisation,

- La Cour Commune de justice et d'Arbitrage (CCJA), intervenant comme Cour Supranationale autant que comme structure d'appui à l'arbitrage, ayant son siège à Abidjan en Côte d'Ivoire,

- Le Secrétariat Permanent, organe exécutif assistant le conseil des Ministres et chargé de la gestion quotidienne de l'Organisation, dont le siège se trouve à Yaoundé au Cameroun,

- L'Ecole Régionale Supérieure de la Magistrature (ERSUMA), ayant son siège à Cotonou au Bénin.

Les membres de l'OHADA sont au nombre de 16 pays tous juridiquement proches de la République Démocratique du Congo (système romano germanique). Il s'agit de : la Guinée Bissau, le Burkina Faso, le Bénin, la Centrafrique, le Niger, la Côte d'Ivoire, le Cameroun, le Sénégal, le Togo, le Tchad, la République du Congo, le Gabon, la Guinée Equatoriale et la Guinée, les Comores.

Huit Actes uniformes sont en vigueur à ce jour :

I. Acte uniforme relatif au droit commercial général,

II. Acte uniforme relatif au droit des sociétés commerciales et du groupement d'intérêt économique,

III. Acte uniforme portant organisation des sûretés,

IV. Acte uniforme portant organisation des procédures simplifiées de recouvrement et des voies d'exécution,

V. Acte uniforme portant organisation des procédures collectives d'apurement du passif,

VI. Acte uniforme relatif au droit de l'arbitrage,

VII. Acte uniforme portant organisation et harmonisation des comptabilités des entreprises,

VIII. Acte uniforme relatif aux contrats de transport de marchandises par route.

22

II.4 .2. L'adhésion de la RDC à l'OHADA

Au conseil des Ministres du 10 Février 2006, le Gouvernement Congolais a pris la décision d'adhérer à l'OHADA. A partir de cette date, les étapes suivantes ont déjà été franchies :

- Le 26 février 2008, le Président de la République a adressé à son homologue du Sénégal, avec copie au Secrétaire Permanent de l'OHADA, la lettre d'intention de la République Démocratique du Congo.

- Le 29 Avril, le Secrétaire Permanent de l'OHADA a répondu au Directeur de cabinet du Président de la République (cf. lettre n°115/SP/DAJ/OHADA/2008) ;

- Le 14 août 2008, le Ministre de la Justice et Droits Humains a obtenu la copie certifiée conforme du traité de Port-Louis ainsi que le règlement portant mécanisme de financement autonome de l'OHADA (cf. lettre de demande de SEM Ministre de la Justice et Droits Humains n°1123/SP/DDL986/NC/CAB/MIN/JHDH/2008 et de transmission du Secrétaire Permanent de l'OHADA n° 232/SP/DAJ/OHADA/2008).

L'adhésion effective de la RDC à l'OHADA a été en date du 26.02.2011.

A l'issue de ce processus, le droit congolais des affaires va disposer de règles simples qui contribueront à l'amélioration du climat des investissements et au renforcement de l'attractivité de la République Démocratique du Congo, avec comme effets d'entraînement la compétitivité des entreprises, la croissance économique et le développement.

En plus, les entreprises congolaises pourront désormais présenter à l'administration fiscale des comptes plus transparents et bénéficier d'une meilleure appréciation du risque par les investisseurs, grâce notamment au nouveau mécanisme de comptes consolidés ou de comptes combinés définis dans le système comptable OHADA (SYSCOHADA).

Il est certain que cette modernisation du cadre légal des affaires en République Démocratique du Congo ne résoudra pas tous les problèmes actuels de ce secteur.

Elle constituera néanmoins un progrès considérable et une avancée historique par rapport à la situation actuelle. Ce sera déjà un progrès très important pour nos entreprises et pour nos partenaires.

En définitive, il faut aussi noter que notre système comptable congolais appelé généralement le Plan Comptable Général Congolais est lacunaire et vétuste par rapport à plusieurs systèmes Comptables internationaux, d'autant plus qu'il émane des quatrième et septième directives du Plan Comptable Français de 1957, alors que ce dernier a déjà connu plusieurs

23

amendements et innovations, notamment avec les IFRS et les IASC. Il nous paraît aujourd'hui évident que notre grand pays ne pourra remédier rapidement aux nombreuses insuffisances de son environnement juridique des affaires qu'en intégrant l'OHADA, qui constitue aujourd'hui un espace juridique unifié de référence reconnu mondialement et fierté de notre continent.

II.5. L'INFORMATISATION DE LA COMPTABILITE

II.5.1. Nécessités et enjeux de l'informatisation de la comptabilité

La comptabilité des entreprises est maintenant systématiquement tenue sur informatique.

L'utilisation aussi massive de l'outil informatique se justifie par :

> La présence de nombreuse tâches répétitives à faible valeur ajoutée (ex : report des comptes du journal vers le grand-livre, l'établissement du compte de résultat, ...) et chronophages qu'il était facile d'automatiser (ex : élaboration de la déclaration de TVA, échéancier des créances et dettes, ...) ;

> La nécessité de contrôler la validité des informations comptables saisies (ex : respect du principe de la partie double, ...) et des traitements comptables effectués (ex : calcul du résultat comptable, ...) ;

> Le besoin accru d'informations élaborées (obtenues suite à un retraitement des informations brutes saisies) pour aider à la prise de décision (ex : calcul de seuils de rentabilité, calcul d'un coût de production, ...) dans un laps de temps suffisamment court (ex : Etat des créances clients impayées,...) ;

> Le travail en réseau (ex : transmission des données à l'expert-comptable, utilisation des données par le contrôleur de gestion, ...) ;

> La recherche d'une plus grande productivité (ex : la validation d'une facture par un commercial génère automatiquement l'écriture correspondante, ...) ;

II. 6. L'IMPACT DE L'INFORMATISATION SUR LE TRAITEMENT DE L'INFORMATION COMPTABLE

L'informatisation du traitement de l'information comptable a profondément modifié le

travail de la fonction comptable. Cela s'est traduit par :

> Un changement de la nature des tâches accomplies. Les tâches de saisie et d'élaboration de l'information comptable ont fortement diminuées pour laisser la place à des tâches de

24

contrôle, d'analyse et de diagnostic. La fonction comptable devient un outil d'aide à la décision (ex : calcul de coûts de revient, calcul de rentabilité, ...).

? Une plus grande communication avec les acteurs internes (ex : notification des créances impayées au service commercial, ...) et externes (ex : négociation des financements à cout termes avec le banquier, ...).

? L'acquisition de compétences informatiques, pour configurer, gérer et utiliser les outils informatiques utilisés (ex : paramétrage du logiciel de comptabilité, ...) et pour être à même de partager et sécuriser les informations hébergées dans le réseau informatique de l'entreprise.

II.6.1.. Les caractéristiques fonctionnelles des logiciels adaptés à la gestion comptable

Pour saisir et produire des informations, la fonction comptable à recours à divers logiciels, dont :

? Le tableur : Le tableur est un outil qui permet la réalisation de calculs répétitifs de manière automatisée et l'élaboration de simulations. Les résultats obtenus peuvent être présentés sous forme graphique. Exemples de tableurs : Microsoft Excel, Calc, ...

? Le progiciel comptable : Le progiciel comptable est un outil qui permet de réaliser les opérations de comptabilité (enregistrement des écritures, édition des documents de synthèse, ...). Il se compose souvent de plusieurs modules (comptabilité, gestion commerciale, paie, ), dont certains permettent de générer directement les écritures comptables (ex : gestion commerciale, paie, ...) et de les exporter vers le module de comptabilité.

? Le PGI (progiciel de gestion intégré) : Le PGI est une évolution des progiciels comptables. Bâti autour d'une seule base de données centralisée, le PGI est composé de modules répondant aux besoins de l'ensemble des acteurs de l'entreprise (service comptable, service commercial, service production, ...). Chaque module permet de générer ou d'utiliser les informations comptables (ex : la validation d'une facture par un commercial génère automatique l'écriture comptable associée, le commercial est à même de savoir si un client a bien réglé l'intégralité de ses factures, ...).

- Questions : Le stock est-il efficacement géré au sein des Ets Tsangamusa ? Sinon, qu'est ce qui expliquerait la mauvaise gestion ?

25

CHAPITRE II : LES ETUDES PREALABLES ET DETAILLEES

II.0. REVUE DE LITTERATURE

1. Muhindo Muyisa, Formalisation informatique de la comptabilité hospitalière en RDC,cas des Centres de Santé,UNILUK, 2008-2009.

Problèmes : il est partit d'un problème de lenteur qui s'observe dans le traitement et production des données relatives à la comptabilité. Passant par les opérations qui se font encore manuellement entraînent un casse-tête dans le service de la comptabilité ; ce qui est à la base de l'imprécision dans les calculs, l'incrédibilité des états financiers produits, la mauvaise tenue des documents comptables et inexistence de certains d'entre eux.

Questions : y a-t-il moyen de rationaliser l'exploitation de la comptabilité dans les institutions de santé en y appliquant les nouvelles technologies de l'information (NTI) ?

Hypothèses : Il est fort à dire qu'il y aurait possibilité d'exploiter au maximum la comptabilité dans les institutions sanitaires de premier échelon en concevant un système automatisé de gestion de la comptabilité dans ces institutions.

Résultat : Conception d'un logiciel de comptabilité

Limites : Le programme ne prend en compte que la gestion comptable et le stock.

2. Kambale Nzalamingi, Modélisation d'un système d'information informatisé et la

conception d'une base de données de gestion du stock : Cas des Ets
Tsangamusa,UNILUK,2009-2010.

Problèmes : Evoquant les problèmes de la gestion de stock dues aux traitements manuels , des erreurs fréquentes dans le traitement des données et la production de documents synthétiques relatifs au système de gestion de stock dus à la croissance de l'entreprise d'une part et de la clientèle au sein des PME en général et de Ets Tsangamusa en particulier de l'autre part.

26

Dans quelle mesure le Système Informatique peut-il alléger la tâche de gestion de stocks au sein de ces derniers ?

- Hypothèses :

· Il se pourrait que la gestion de stock des ETS TSANG ne soit pas bien efficace et que cette situation soit due au nombre élevé d'articles, des clients et la tenue manuelle de fiche de stocks qui présentent un sérieux problème.

· Il serait possible que la modélisation d'un système d'information informatisé et la conception d'une base de données appropriée pour la gestion du stock allégerait la situation.

- Résultat : Conception et mise en place d'un système d'information informatisé avec une base de données capable d'être utilisée par le service de gestion des stock selon le système comptable en palliant au problème de la valorisation des stocks, du contrôle des entrées et des sorties, l'inventaire selon de théories reconnues par les normes générales de la comptabilité et aussi adaptées à l'environnement spécifique des ETS TSANG.

Limites : Le programme n'a traité que l'aspect de gestion de stock.

3. ISMAILA Mchangama, Conception et développement d'un logiciel de gestion commercial, Mémoire, Université de Monastir, 2006-2007

Problèmes : · de l'analyse de l'existant il a trouver ce qui suit : L'abondance des documents dans l'entreprise peut ralentir les services.

· On peut en avoir besoin de plus d'employés pour se partager les taches.

· Risque de mélanger les documents : ce qui peut être fatal.

· La suivie des clients et des fournisseurs peut rencontrer beaucoup de problèmes.

· La perte de la clientèle est possible au cas où le traitement de leurs demandes traine

Questions : vu l'intérêt croissant de vouloir gagner en temps, de conserver les données, de limiter le nombre d'employés et pas mal d'autres raisons au sein de petites, moyennes et grandes entreprises, Quelles solutions informatiques capables de répondre à leurs besoins ?

27

Hypothèses : réaliser une application sur mesure de gestion commerciale pour une société de ventes des matériels informatiques.

Résultat : conception et à développement d'une application informatique permettant la gestion automatique des clients, des fournisseurs, du stock.

Limites : le projet était borné à la seule entreprise de ventes informatiques et non à n'importe quelle entreprise commerciale et sans prise en compte de la comptabilité financière du stock.

II.1. DEFINITION DES OBJECTIFS :

Cette étape consiste à définir la finalité du projet et son inscription dans une stratégie

globale.

En ce qui nous concerne, la finalité de notre projet est de produire un logiciel intégrant :

- La gestion de stock,

- La gestion de paie du personnel et

- La comptabilité générale sous le modèle du système Comptable OHADA avec un

applet sur la gestion des immobilisations.

L'aspect budgétaire ne sera pas pris en compte dans le cas de ce travail car requiert une

comptabilité particulière et aussi à cause de quotas de temps impartis.

Au terme de notre projet ; sa réalisation apportera une aide considérable dans le métier du

comptable de PME qui ne voit augmenter le volume d'informations à traiter du jour le jour avec le

système manuel ou automatique malheureusement pas sur mesure.

C'est pourquoi, il nous est indispensable de bien recueillir les besoins des utilisateurs(PME) et

tenter à les conscrire dans une optique de faisabilité afin de produire le cahier de charges.

II.1. ANALYSE DES BESOINS ET FAISABILITE :

C'est-à-dire l'expression, le recueil et la formalisation des besoins du demandeur (le client)

et de l'ensemble des contraintes, puis l'estimation de la faisabilité de ces besoins.

II.2.1. Analyse de l'existant

Dans cette section nous présentons les différents programmes repris dans la section de la

revue de littérature ; il nous sera exactement nécessaire de donner les différents Modèles Conceptuel de Données :

28

Médicament

CodMat DesignMat FormMat CondMat DosMat StockMax StockAl

II.2.1.1. Formalisation informatique de la comptabilité hospitalière en RDC, cas de Centres de Santé



Exercice

CodExercice

1, N

Compte Principaux

NumFic NomMal AdMal TelMal

Prévoir
MontPrev
ModifMont

1, N

0, N

0, N

NUmCompPrinc DesignCompPrinc TypeCompPrinc STypeCompPrinc NatSoldCompPrinc MassBilanComptPrinc

Avoir

Contenir

1, 1

1, 1

Opération

Imputer

0, N 1, N
MontDeb

MontCred

NUmOp DateOp NumPj LibelleOp TauxJour

Compte Division

1, 1

Utiliser

0, n

Transaction stock

1, 1

0, n

Monnaie

CodMonnai NomMonnai

QuantEntre PrixUnitEntre NomFour Reference QuantSort

NUmCompDiv DesignCompDiv TypeCompDiv STypeCompDiv NatSoldCompDiv MassBilanComptDiv

Figure 2: MCD CSCompta

Malade



Client

NumClient NomClient

Commander

NumCmdClient Date

Facture

NumFact

Date

ModPeyement

Passer

Facture

1, 1

1, n

1,1

1, n

1,n

1, n

Sortie QteSort

Vendre
Qtev,
Pv

Categories

NumCatg NomCatg

1, n

Commander QteCmdClient

1, n

1,n

1, n

Arrivage NumArrivg DepenseArrivg

1, n

Sorties

NumBonSort DatBonSort

Avoir

Appartient

Lots

NumLot

1, 1

1, n

Appartenir

1, n

1,n

1, n

1, 1

1,n

Article

NumArt NomArt DescriptArt

Planifier

StockMin, StokMax StockAlert, TVA

ExerciceComptable

ExeCompt

Qte

Entree

NumBonEntr QteEntre

Entrer

1, n

1, n

1, n

1,n

1, n

1, n

1,n 1,n

Requisitioner Qte

Acheter Qte,PA

1, n

1, n

Facture d'Achat

NumfactAch Date

Fournisseur

NumFsseur NomFsseur

NumReq DatEmReq

1, n

29

II.2.1.2. Modélisation d'un système d'information informatisé et la conception d'une base de données de gestion du stock des Ets

Tsang

Requisition

30

Figure 3: MCD Gestion de Stocks TsangCom

II.2.1.3. Logiciel de Gestion Commerciale



(Nous nous excusons de la qualité d?impression de cette page car les sources nous ont fournis que ceci.)

Figure 4: Modèle de Classe Gestion Commerciale

31

II.3. OPPORTUNITE DU PROJET

L'étude de l'opportunité du projet implique la recherche de la réponse à la question suivante : le projet est-il utile par rapport aux véritables objectifs de l'entreprise? La réponse à cette question nécessite la vérification de la concordance entre les objectifs du projet et ceux des PME en RDC en général à travers les structures chargées de la gestion du stock, gestion comptable et gestion du personnel.

Ambitions informatiques des PME

D'après les enquêtes sur terrain de K. Musumba(2009-2010), aux questions selon lesquelles, envisagez-vous un jour utiliser l'ordinateur pour vous aider dans la gestion de votre entreprise et pour quelle raison désirez-vous utiliser cet outil de gestion ? 75% de la population d'étude soit 9 enquêtés sur 12 ont répondis qu'ils envisagent utiliser les nouvelles technologies de l'information et de communication pour les aider dans la gestion de leur entreprises et 25% soit 3 enquêtés disent qu'ils n'envisagent pas un jour faire recours aux nouvelles technologies de l'information et de communication.

Considérant le mobile d'utilisation des TIC dans les PME commerciales en ville de Butembo, 9,1% soit 1 enquêté a répondu que l'intégration des TIC serait du à l'aide à la comptabilité, 9,1% soit 1 enquêté a dit que l'intégration de l'outil informatique dans la gestion serait du à l'aide à la communication, 81,8% soit 9 enquêtés ont dit que les technologies de l'information et de communication soit l'outil informatique, les aideraient à la comptabilité ou à la communication dans leur entreprise et 8,3% soit 1 enquêté s'est abstrait (n'as donné aucun opinion).

II.4. FAISABILITE DU PROJET

Le projet est-il réalisable par rapport aux contraintes de réalisation ? Telle est la question à laquelle il faut répondre dans ce point traitant de la faisabilité de notre projet en fonction des opportunités et des menaces de l'environnement.

a) atouts

Pour réaliser ce projet, les PME présentent des atouts en hommes, matériels, logiciels

et temps.

32

? Opportunités humaines :

Avec la poussée technologique en vogue, les PME commerciales congolaises disposent au moins du service informatique dans lequel l'on manipule les informations de l'entreprise. De ce fait, dans leur plan informatique et vu la nouvelle réglementation du SYSCOHADA ; sont comme obligées d'en former les utilisateurs futurs et d'y migrer.

La présence d'un bon nombre des diplômés en Gestion informatique ne fait qu'ouvrir un fois de plus la porte aux PME vers une gestion efficace et efficiente de leur structure.

? Opportunités matérielles et logicielles :

Les PME commerciales en ville de Butembo sont prêtes à intégrer les nouvelles technologies de l'information et de communication voire la fréquence des répondants face à cette question, qui est de 9 enquêtés soit 75%. (K. Musumba,2009-2010).

Par observation directe, il apparait que la plupart de PME Commerciales congolaises utilisent un ordinateur et ce dernier contient les programmes contenus dans le paquet Ms Office de la Maison Microsoft ; ces programmes fort utiles pour l'automatisation de certaines de tâches.

? Opportunités temporelles :

Les cinq mois à notre disposition pour réaliser notre projet sont bien suffisants. Nous sommes convaincus que nous les gérerons efficacement et rationnellement en vertu des normes impératives de la planification des projets.

b) Contraintes

Le coût d'acquisition élevé des outils TIC reste le facteur principal de blocage de l'intégration des TIC dans les PME commerciales en ville de Butembo car partant des résultats obtenus face à cette question, 58,3% soit 7 enquêtés confirment que le coût élevé d'acquisition des outils TIC leur reste un facteur de blocage.

Ces résultats sont à inférer sur l'ensemble des PME commerciales congolaises et cela serrait la même chose pour les régions et provinces de l'Equateur, Kisangani, Maniema et Katanga.

D'autre part, l'insuffisance d'alimentation en courant électrique sur presque toute l'étendue de la RDC serait aussi un goulot d'étranglement.

De l'analyse des atouts et contraintes, il ressort que le projet est faisable vu que la loi de Moore peut être d'applicabilité et une réalité dans les années à venir en RDC par rapport aux coût d'acquisition des outils de TIC et son plan national de développement(5 chantiers) pour

33

l'électricité ; et l'usage de groupe électrogènes est monnaie courante en cas d'absence d'énergie électrique dans la plupart de contrées de la RDC.

De ce qui précède, les PME commerciales congolaises devraient avoir à leur sein une base de données gérant efficacement ses activités commerciales, la rémunération de ses employés et la comptabilisation de toutes ces activités ; attendu que le système comptable congolais régis par le PCGC est caduque début 2012 sur toute l'étendue nationale ; il est avantageux d'intégrer un logiciel prenant en les grandes modules cités supra en respectant les normes du génie logiciel lors de sa conception dans le SYSCOHADA.

Notre cahier des charges étant constitué, il nous est possible de passer à la conception de la solution.

Conclusion : Dans cette section nous sommes partis de la revue de littérature afin d'interroger nos prédécesseurs sur la problématique ayant retenus notre attention, et avons constaté que le sujet était abordé en partie et non dans le contexte qui est le notre. Une étude d'opportunité et de faisabilité a été mené en analysant l'existant et les faits ont été concluants départ notre cahier de charges dont la conception de solution devra prendre en compte en utilisant un langage permettant à réaliser les objectifs fixés dans cette section.

34

CHAPITRE III : CONCEPTION DE SOLUTIONS

III.1. SPECIFICATIONS OU CONCEPTION GENERALE :

Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel.

Sachant que notre application contiendra la Gestion de Stock et la Gestion Comptable sous le SYSCHOHADA quant à la Gestion de Paie du personnel ne sera que modéliser compte tenu de différentes contraintes.

III.1.0. Généralités sur le Diagramme de cas d'utilisation

Ce diagramme est destiné à représenter les besoins des utilisateurs par rapport au

système. Il constitue un des diagrammes les plus structurants dans l'analyse d'un système.

· Acteur : Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel ou autre système) qui interagit directement avec le système étudié.

· Cas d'utilisation (use case) : Représente un ensemble de séquences d'actions qui sont réalisées par le système et qui produisent un résultat observable intéressant pour un acteur particulier.

· Les relations entre acteurs : La seule relation entre acteur est la relation de généralisation. Quand un acteur fils hérite d'un acteur père, il hérite en réalité de toutes les associations du père.

· Les relations entre cas d'utilisation :

Relation d'inclusion : Une relation d'inclusion d'un cas d'utilisation A par rapport à un cas d'utilisation B signifie qu'une instance de A contient le comportement décrit dans B.

Relation d'extension : Une relation d'extension d'un cas d'utilisation A par un cas d'utilisation A signifie qu'une instance de A peut être étendue par le comportement décrit dans B.

Relation de généralisation : Les cas d'utilisation descendants héritent de la description de leurs parents communs. Chacun d'entre eux peut néanmoins comprendre des interactions spécifiques supplémentaires.

35

III.1.1. Contexte du système

Pour concevoir et réaliser le système logiciel de gestion de stock intégré à la Comptabilité pour les entreprises commerciales, il nous était indispensable de collecter les informations nécessaires auprès des spécialistes du domaine. Après avoir structuré les informations collectées, nous les présentons de la manière suivante :

III.1.1.1. Circuit du déroulement des activités relatives de la Gestion de Stock

Nous subdivisons la gestion de stock au sein des PME en 4 grandes parties dont :

1. Des Entrées en stock de la marchandise

Apres que la réquisition soit élaborée par le magasinier et approuvée par l'approvisionneur, elle est lancée vers les fournisseurs déjà choisis par l'entreprise selon les types de marchandises (produits) ; et le fournisseur dans un premier cas enverra la facture d'achat, l'approvisionneur la présentera à la caisse après quelques amendements par le comité de gestion commerciale (PDG, Comptable et Gérant) et de part la disponibilité de la caisse il décidera d'honorer la facture selon le mode de payement préétablis et convenu ou chercher un autre fournisseur à bon prix.

Dans le cas échéant, le fournisseur enverra la marchandise accompagnée du bon de livraison ; lorsque la marchandise arrive, elle est réceptionnée par le magasinier et l'approvisionneur afin de comparer le bon de livraison à la réquisition établie. S'il y a correspondance, la marchandise sera classée selon le type de produit par pointage et son enregistrement dans le registre d'arrivages. Dans le cas échéant l'on établira une notes de remarque vers le fournisseur pour lui tenir informer du ladite situation. L'on élaborera le bon de réception ou le bon d'entrée pour les marchandises effectivement entrer dans le stock (dépôt).

A cette phase d'entrée, les documents suivants sont utilisés :

? la facture d'achat du fournisseur, ? le bon de livraison du fournisseur, ? le registre d'arrivages,

? la Fiche de pointage, et

? le bon de réception (bon d'entrée)

2. Du Stockage de la marchandise

Après que l'entrée de la marchandise soit effective au niveau de l'entreprise, elle passe dans le processus du stockage. Ce dernier se fait aussi par type du produit et permet l'établissement d'une fiche de Stock.

Le seul document utilisé est la Fiche de Stock.

3. 36

De la Sortie de la marchandise La sortie se fait de trois manières :

? Pour la sortie au comptant : la commande est déclenchée par un client au point de vente (guichet). Le vendeur élaborera le Bon de Commande, puis remettra ce dernier sous forme de la Facture. Le client exhibera la facture et la déposer au/àla caissier(ère) qui à son tour établira et lui donnera le reçu de payement après versement de la somme correspondante et enverra le client auprès du magasinier pour la édition du bon de livraison et la remise de la marchandise. Le reçu sera déposer au magasinier pour d'éventuels contrôles internes. Tandis que le bon de livraison sera emporté par le client et sa marchandise.

? Pour la sortie à terme (à crédit): le client se présentera au poste du PDG ou le Chef
Comptable seuls à l'amabilité d'accorder le crédit, solliciter la marchandise à court terme. Lorsque cette dernière est validée, on élabore le bon de crédit qui sera présenté au dépôt pour la sortie de la marchandise.

? L'envoi de la marchandise aux succursales (si l'entreprise a à son sein une
succursale): la succursale enverra la commande de produits par un bon de commande à la maison Mère puis celle-ci s'assure si les produits demandés existent bel et bien en stock afin d'envoyer la marchandise accompagnée d'un bon de sortie en dépôt.

4. Lors du réapprovisionnement

Lors du réapprovisionnement de la marchandise, l'on passera à première vue à la vérification des marchandises sorties dans le registre de sortie en dépôt(Fiche de Stock informatisé) en mettant l'emphase sur les produits ayant accusé une grande fréquence de sortie, puis le magasinier élabore la réquisition à soumettre à l'approvisionneur qui devra être approuvé par le PDG et enfin envoyé vers les fournisseurs préalablement choisis par l'entreprise. La réquisition sera datée et classée selon l'ordre d'émission.

Les documents nécessaires pour ce processus sont : Le registre des sorties, Registre des

ventes et Fiche de stock.

Ces enchainements d'activités et traitements sont formalisées par le diagramme d'activité d'UML suivant :



37

Figure 5: Diagramme d'activité de la gestion de stock

38

III.1.1.2. Circuit du déroulement des activités relatives à la Gestion de Paie

La gestion de la paie constitue un aspect important de l'administration des salaires.

Le chargé de Ressources humaines recevra les fiche de prestations des employés et les soumettront à l'analyse auprès du trésorier pour différents calculs liés au salaire. Ce dernier élaborer la fiche de paie à l'aide de la fiche de prestation et l'enverra au près du caissier pour payer les employés ; ensuite un rapport de paie sera envoyé au trésorier pour contrôle et c'est après amendement s'il n y avait pas de différend par son accord qu'il sera envoyé à la comptabilité pour traitement

Ces enchainements d'activités et traitements sont formalisées par le diagramme d'activité d'UML suivant :



Figure 6: Diagramme d'activité de la gestion de paie

39

III.1.1.3. Circuit du déroulement des activités relatives la Gestion Comptable

La Gestion de Comptable dans les entreprises commerciales se passera de cette façon :

Les différents départements c'est-à-dire la caisse, la trésorerie, commercial, Ressources humaines, etc. enverront les différentes pièces justificatives (facture, reçu, bon de commande, bon d'entrée, etc.) à la comptabilité.

Le comptable recevra ensuite ces pièces et les enregistrer. Chaque département doit avoir un sous compte à la comptabilité lequel facilitera l'imputation (débiter ou créditer) des différentes charges ; le comptable créera ensuite le compte pour chaque département s'il n'existe pas et passera différentes écritures liées au compte départ les pièces justificatives

dument présenté. Si l'écriture a été mal passée il y a possibilité d'éventuelles corrections. La
comptabilité établira les différents états financiers et les enverront à qui de droit (départements).

Ces enchainements d'activités et traitements sont formalisés par le diagramme d'activité d'UML suivant :



Figure 7: Diagramme d'activité de la gestion comptable

40

III.1.2. Diagramme du contexte

Au cours de cette étape nous allons réaliser le diagramme de contexte. L'application étant une boite noire qui interagit avec les déférents acteurs. Des liens relient l'application à chacun des acteurs sur lesquels sont montrés les messages en entrée et en sortie de l'application.

Avant de présenter le diagramme du contexte, l'identification des acteurs communiquant avec le système ainsi que les messages qui transitent de part et d'autre est indispensable.

III.1.2.1 Identification des acteurs

Dans cette étape, nous allons identifier les différents acteurs qui interagiront avec l'application.

Le magasinier : peut consulter l'état du stock, gérer les bons de sorties et les bons d'entrées, établir les bons de commandes internes et les bons d'entrées ainsi que les bons de sortie, et enfin mettre à jour l'état du stock, des produits et leurs catégories correspondantes, des fournisseurs avec lesquels traitent etc.

L'approvisionneur : hérite tout ce que fait le magasinier et considéré comme l'administrateur du système.

Le vendeur : peut consulter l'état du stock, établir et éditer les bons de commandes émanant de clients. Et aussi transformer le bon de commande en Facture de vente du client.

Le fournisseur : envoie la facture d'achat, les produits ou marchandises et le bon de livraison ; peut aussi recevoir une note en cas de non-conformité de la commande.

Le caissier : peut vérifier l'existence du bon de commande seulement et sans le modifier. Il peut encaisser le montant déposer par le client, établir et éditer le reçu de payement. Payer le personnel et établir le rapport de paie.

Le Comptable : peut réceptionner les pièces justificatives provenant des différents services, les enregistrer, créer un compte et le gérer, imputer un compte, établir et éditer les états financiers. Le trésorier : hérite du comptable et peut analyser les fiches de prestations, élaborer le la fiche de paie et amender le rapport de paie.

Le Chargé du RH : réceptionne les fiches de prestations et le rapport de paie déjà amandé. L'employé : peut percevoir le salaire.

41

III.1.2.3. Identification des messages

Un message est une information envoyée par un émetteur dont le but de déclencher une activité chez le récepteur. Voici la liste des messages échangés entre l'application et ses acteurs :

Messages envoyés acteur système	Messages réponses système acteur
M1 : Authentification.	M2 : Interface d'authentification.
M3 : Consultation de l'état du stock.	M4 : Interface de consultation adéquate.
M5 : Gérer les bons d'entrée.	M6 : Interface gérer les bons d'entrée.
M7 : Editer un bon de commande Client	M8:Interface éditer un bon de commande
M9 : Gérer les bons de sorties.	M10 : Interface gérer les bons de sorties.
M11 : Editer un bon de sortie	M12 : Interface éditer un bon de sortie.
M13 : Editer un bon de livraison	M14 : Interface éditer un bon de livraison
M15 : Editer une facture	M16 : Interface éditer une facture de vente
M17 : Editer un reçu de payement	M18 : Interface éditer un reçu de paiement
M19 : Mettre à jour les fournisseurs.	M20 : Interface de mise à jour adéquate.
M21 : Mettre à jour les produits.	M22 : Interface de mise à jour adéquate.
M23 : Gérer un compte	M24 : Interface gérer un compte.
M25 : Imputer un compte	M26 : Interface imputer un compte
M27 : Gérer le personnel	M28 : Interface gérer personnel
M28 : Payer personnel	M29 : Interface payer personnel
M30 : Mettre à jour les services.	M31 : Interface de mise à jour adéquate.
M32 : Mettre à jour Base de données	M33 : Interface de mise à jour adéquate

Tableau 1: tableau des messages en interaction

42

Diagramme de contexte



Figure 8: Diagramme de contexte de l'application III.1.3. Diagramme de cas d'utilisation

Ensemble de séquences d'actions réalisées par le système (comportement attendu considéré comme un tout) et qui produit un résultat voulu par un acteur.

On cherche à identifier un comportement (ce qu'il doit faire) et non la façon dont ce comportement sera mis en oeuvre (comment il le fait).

III.3.1. Diagramme de cas d'utilisation : Gestion de Stock

Description textuelle des différents cas d'utilisation

Authentifier : Permet à un acteur de s'authentifier avant d'accéder à l'application.

Vérifier le stock: Permet aux différents acteurs d'avoir une consultation sur les différents produits du dépôt (magasin).

Réquisitionner : Permet au magasinier d'élaborer la réquisition et l'envoyer à l'approvisionneur pour amendement.

Réceptionner marchandise : Permet au magasinier et l'approvisionneur de recevoir le bon de livraison de marchandises venant du fournisseur accompagnées des marchandises. Afin de faire certaines vérifications.

Etablir un bon de commande client: Donne la possibilité aux services demandeurs (Clients, succursales, etc.) d'exprimer leurs besoins envers le vendeur.

43

Gérer Facture : Permet au Vendeur d'effectuer des opérations sur la Facture ; elles concernent : l'ajout, la modification et la suppression. .

Gérer les bons de sorties: Permet au magasinier d'effectuer des opérations sur les bons de sorties. Ces opérations concernent : l'ajout, la modification et la suppression.

Gérer les bons d'entrées : Permet au magasinier et à l'approvisionneur d'effectuer des opérations sur les bons d'entrées. Ces opérations concernent : l'ajout, la modification et la suppression.

Encaisser : Permet au caissier d'encaisser le montant déposer par le client.

Gérer le reçu de payement : Permet au caissier d'établir le reçu de payement lié à la Facture du client après encaissement.

Editions: Permet aux différents acteurs, selon leurs droits d'accès, d'éditer différents documents (bon de commande, bon de sortie, bon d'entrée, Fiche de stock, Facture, reçu, bon de livraison). Tenir fiche de stock : Permet au magasinier de mettre à jour la fiche de stock en entrée de produit comme à la sortie dans le stock.

Mise a jour de la base de donnée : Permet à l'approvisionneur (administrateur du système) de mettre a jour sa base de donnée. Cette mise à jour concerne : les fournisseurs, les services, les

produits, les emplacements et les types des produits.

44

Les principales fonctionnalités de l'application à concevoir sont érigées autour des besoins et exigences des différents acteurs. Elles sont illustrées dans le diagramme du cas d'utilisation de la gestion du stock suivant :



Figure 9: Diagramme de cas d'utilisation de la gestion de stock

Envoyer rapport paie : Permet au trésorier d'envoyer au comptable le rapport de paie après amendements si nécessaire, afin d'imputer différents comptes.

45

III.1.5. Diagramme de cas d'utilisation : Gestion de Paie



Figure 10: Diagramme de cas d'utilisation la de Gestion de Paie

Description textuelle des différents cas d'utilisation

Authentifier : Permet à un acteur de s'authentifier avant d'accéder à l'application.

Recevoir fiche de prestation : Permet au chargé du personnel de vérifier la prestation de son personnel.

Analyser fiche de prestation : Permet au trésorier d'appliquer certains calculs par rapport aux prestations des employés.

Elaborer fiche de paie : Permet au trésorier après différents calculs d'élaborer la fiche de paie du personnel selon le niveau.

Payer personnel : Permet au Caissier de payer le personnel à la fin de chaque mois.

Recevoir rapport paie : Permet au trésorier de recevoir le rapport de paie élaboré par le caissier après payement et susceptible de corrections et envoi une copie au chargé du personnel pour information et classement.

46

III.1.6. Diagramme de cas d'utilisation : Gestion Comptable



Figure 11: Diagramme de cas d'utilisation de la Gestion Comptable

47

Description textuelle des différents cas d'utilisation

Authentifier : Permet à un acteur de s'authentifier avant d'accéder à l'application.

Envoyer Etats financiers : Permet au comptable d'envoyer les rapports financiers aux différents départements.

Réceptionner pièces justificatives : Permet au comptable de recevoir les pièces justificatives émanant de différents départements.

Enregistrer pièces justificatives : Permet au comptable de saisir les différentes pièces dans la base de données.

Gérer compte : Permet au comptable de créer un compte, de le supprimer et le modifier en cas de besoin.

Imputer compte : Permet au comptable d'affecter à chaque compte selon les pièces justificatives en sa possession différentes charges y relatives.

Corriger écriture : Permet au comptable de corriger certaines imputations.

Etablir états financiers : Permet au comptable d'établir les états de synthèse à envoyer à qui de droit.

III.2. CONCEPTION DETAILLEE :

Cette étape consiste à définir précisément chaque sous-ensemble du logiciel.

Nous présentons dans cette section les différentes classes de notre application à implémenter.

Les diagrammes de classe partiels sont établis au fur et à mesure de l'établissement des diagrammes de séquence. Ensuite on regroupe le tout pour créer un diagramme de classes complet.

III.2.1. Diagrammes de Classes Gestion de Stock a. Règles de Gestion

1. Un exercice comptable est identifié par un code exercice, a une date début et une date fin.

2. Un produit est caractérisé par un Code du produit et a un libellé, prix unitaire et une catégorie.

3. Une catégorie de produits concerne un ou plusieurs produits.

4. Un produit a une et une seule catégorie de produits.

5. Un client est identifié par un code, a un nom, un sexe et une adresse.

6. Un client peut commander un ou plusieurs produits dans une commande.

48

7. Une commande est caractérisée par une Référence de la commande pour un client, a une date et une quantité dans un exercice comptable.

8. Un bon de commande Client contient un ou plusieurs produits

9. Un vendeur a un numéro d'identification et un nom

10. Un fournisseur est identifié par une référence, a un nom, une adresse. Un fournisseur peut nous fournir plusieurs produits dans un exercice comptable. Un fournisseur établit une ou plusieurs factures.

11. La TVA est identifiée par un code, a une période et un taux applicable dans un exercice comptable.

12. L'entrée en stock de produits est caractérisée par un Numéro bon d'entrée, a une date et une quantité d'entrée dans un exercice comptable. Un bon d'entrée concerne un ou plusieurs produits.

13. Un produit peut figurer dans un ou plusieurs bons d'entrée.

14. La sortie en stock de produits est identifiée par un Numéro Bon de Sortie, a une date et une quantité de sortie dans un exercice comptable. Un bon de sortie est associé à un et un seul bon de commande Client.

15. Une vente est caractérisée par un numéro, a une date, un taux de tva, une quantité et un prix de vente dans un exercice comptable.

16. Une vente est associée à une commande client et à une seule facture ayant un ou plusieurs produits.

b. Digramme de Séquence

Il s'agit d'une explication détaillée d'un cas d'utilisation. Les principales informations contenues dans un diagramme de séquence sont les messages échangés entre les lignes de vie, présentés dans un ordre chronologique.

b.1. Diagramme de séquence pour le cas d'utilisation Authentifier

Description textuelle du scénario

Lorsque un utilisateur souhaite accéder à sa session, une page d'accueil lui sera affichée, dans laquelle saisit ses propres coordonnées d'authentification (login et mot de passe).par la suite le système procède a la vérification des informations introduites, si le login et le mot de passe sont valides sa session lui sera alors ouverte, sinon un message d'erreur est affiché le sollicitant de réintroduire ses coordonnées. Ce processus de vérification ce répétera autant de fois que l'utilisateur communique des informations erronées.

49



Figure 12: Diagramme de séquence pour le cas d'utilisation Authentifier

b.2. Diagramme de séquence pour le cas d'utilisation Ajout produit

Description textuelle du scénario

Le magasinier désir ajouter un produit, le système lui demande de saisir les informations y afférentes sans préciser le numéro bon d'entrée car s'agissant du catalogue. Il sélectionne la catégorie de produits, et procède alors à la vérification des différentes informations fournies au clavier puis déclenche le contrôle d'intégrité de la référence du produit. En cas d'absence d'erreur, l'enregistrement sera effectué, sinon toute erreur sera signalée.



Figure 13: Diagramme de séquence pour le cas d'utilisation Ajout produit

50

b.3. Diagramme de séquence pour le cas d'utilisation Gérer un bon de commande Description textuelle du scénario

Le vendeur désir gérer un bon de commande c'est-à-dire ajouter, modifier, et supprimer un bon de commande. Le système lui affiche le formulaire de bon de commande et lui demande de saisir les informations appropriées, par la suite vérifie l'existence du produit demandé et aussi si le client existe dans la base sinon un message d'erreur sera affiché et l'enregistrement du bon de commande sera effectif dans le cas échéant.

Lorsque le vendeur veut modifier un bon de commande suite à une mauvaise saisie, le système procédera à la recherche du Numéro Bon de Commande et affichera les informations y relatives lorsqu'il sera présent dans la base sinon un message d'erreur sera affiché, par la suite vérifiera si toutes les informations sont bel et bien modifiées et déclenchera le processus d'enregistrement.

En cas de suppression, le système recherchera le numéro bon de commande et demandera au magasinier de confirmer la dite suppression sinon rien ne sera fait.



Figure 14: Diagramme de séquence pour le cas d'utilisation gérer un bon de commande

51

b.4. Diagramme de séquence pour le cas d'utilisation Encaisser Description textuelle du scénario

Le Caissier désir encaisser la commande passer par le client, il saisir les informations exigées et au système de procéder à la vérification de l'existence du numéro de la facture et celui de la vente associé puis enregistrera l'encaisse, dans le cas contraire, un message d'erreur sera signalé.



Figure 15: Diagramme de séquence pour le cas d'utilisation Encaisser

52

c. Diagramme de classes



Figure 16:Diagramme de classes Gestion de Stocks

53

III.2.2. Diagramme de Classes Gestion Paie

a. Règles de Gestion

1. Un ouvrier est identifié par un numéro, il a un nom, un post nom et une date d'engagement et l'adresse ;

2. Un ouvrier peut être payé une et une seule fois durant un mois de prestation.

3. Un mois est identifié par un code et a une description ;

4. Un service est caractérisé par un code service et un nom ;

5. Un service contient un ou plusieurs employés durant une période.

b. Digramme de Séquence

b.1. Diagramme de séquence pour le cas d'utilisation Payer employé

Description textuelle du scénario

Le caissier devra consulter la fiche de paie du mois approprié pour les employés concernés. Le système lui affichera la fiche de paie correspondante puis vérifiera si l'employé concerné existe réellement dans la base et physiquement non fictif sinon un message d'erreur sera signalé. Le processus de payement sera effectif lorsque les conditions requises seront remplies.



Figure 17: Diagramme de séquence pour le cas d'utilisation Payer employé

54

c. Diagramme de classes



Figure 18:Diagramme de classes Gestion de Paie

55

III.2.3. Diagramme de Classes Gestion Comptable

a. Règles de Gestion

Nous reprenons ici les extraits des articles 17, 19 et 22 de l'acte uniforme de l'OHADA.

Lorsqu'elle repose sur un traitement informatique, l'organisation comptable doit recourir à des procédures qui permettent de satisfaire aux exigences de régularité et de sécurité requises en la matière de telle sorte que :

1. les données relatives à toute opération donnant lieu à enregistrement comptable comprennent, lors de leur entrée dans le système de traitement comptable, l'indication de l'origine, du contenu et de l'imputation de ladite opération et puissent être restituées sur papier ou sous une forme directement intelligible ;

2. l'irréversibilité des traitements effectués interdise toute suppression, addition ou modification ultérieure l'enregistrement ; toute donnée entrée doit faire l'objet d'une validation, afin de garantir le caractère définitif de l'enregistrement comptable correspondant ; cette procédure de validation doit être mise en oeuvre au terme de chaque période qui ne peut excéder le mois ;

3. la chronologie des opérations écarte toute possibilité d'insertion intercalaire ou d'addition ultérieure ; pour figer cette chronologie le système de traitement comptable doit prévoir une procédure périodique (dite « clôture informatique ») au moins trimestrielle et mise en oeuvre au plus tard à la fin du trimestre qui suit la fin de chaque période considérée ;

4. les enregistrements comptables d'une période clôturée soient classés dans l'ordre chronologique de la date de valeur comptable des opérations auxquelles ils se rapportent ; toutefois, lorsque la date de valeur comptable correspond à une période déjà clôturée, l'opération concernée est enregistrée au premier jour de la période non encore clôturée ; dans ce cas, la date de valeur comptable de l'opération est mentionnée distinctement ;

5. la durabilité des données enregistrées offre des conditions de garantie et de conservation conformes à la réglementation en vigueur. Sera notamment réputée durable toute transcription indélébile des données qui entraîne une modification irréversible du support ;

6. l'organisation comptable garantisse toutes les possibilités d'un contrôle éventuel en permettant la reconstitution ou la restitution du chemin de révision et en donnant droit d'accès à la documentation relative aux analyses, à la programmation et aux procédures des

56

traitements, en vue notamment de procéder aux tests nécessaires à l'exécution d'un tel contrôle ;

7. les états périodiques fournis par le système de traitement soient numérotés et datés. Chaque enregistrement doit s'appuyer sur une pièce justificative établie sur papier ou sur un support assurant la fiabilité, la conservation et la restitution en clair de son contenu pendant les délais requis.

Chaque donnée, entrée dans le système de traitement par transmission d'un autre système de traitement, doit être appuyée d'une pièce justificative probante.

b. Digramme de Séquence

Nous présentons ici une vue globale du diagramme de séquence par simplification :



CP : Compte Principal ; CD : Compte Divisionnaire

Figure 19: Digramme de Séquence Gestion Comptable

57

a. Diagramme de classes



Figure 20:Diagramme de classes Gestion Comptable

Conclusion : Cette section nous a permis de modéliser le système en commençant par le diagramme de cas d'utilisation qui nous a permis de déceler les besoins de futurs utilisateurs. Par ailleurs, le diagramme de séquence nous a conduit à avoir les différentes fonctions du système et quant au diagramme de classes l'aperçu statique du système. L'étape de programmation prendra en compte toutes les spécifications fournies lors de la phase d'analyse et conception.

58

Chapitre IV : REALISATION DE LA SOLUTION

En pratique, la dernière activité du Processus Unifié est composée de deux parties

implémentation et test. Elle a comme objectif d'aboutir à un produit final, exploitable par les utilisateurs. Dans cette phase nous allons présenter l'environnement de développement que nous avons utilisé, l'architecture matérielle mise en place pour implémenter tous les cas d'utilisation, et enfin les tester.

IV.1. IMPLEMENTATION DE LA SOLUTION

C'est la traduction dans un langage de programmation des fonctionnalités définies

lors de phases de conception.

IV.1.1. Environnement de développement de l'application

Pour réaliser notre application, nous avons utilisé le langage de programmation C#

2008 dédié à la POO afin de créer des applications exécutables et indépendantes dans l'environnement Client/serveur utilisant les bases de données de la plate forme Microsoft.

Environnement Dia nous a permis dans la modélisation en nous produisant de diagrammes appropriés dans l'Orientée Objet. Pour produire des interfaces ergonomiques, nous avons utilisé Adobe Photoshop pour les traitements des images de notre application.

IV.1.1.1. Microsoft Visual Studio

Microsoft Visual Studio est une suite de logiciels de développement pour Windows conçu par Microsoft. La dernière version s'appelle Visual Studio 2010.

Visual Studio est un ensemble complet d'outils de développement permettant de générer des applications Web ASP.NET, des Services Web XML, des applications bureautiques et des applications mobiles. Visual Basic, Visual C++, Visual C# et Visual J# utilisent tous le même environnement de développement intégré (IDE, Integrated Development Environment), qui leur permet de partager des outils et facilite la création de solutions faisant appel à plusieurs langages. Par ailleurs, ces langages permettent de mieux tirer parti des fonctionnalités du Framework .NET, qui fournit un accès à des technologies clés simplifiant le développement d'applications Web ASP et de Services Web XML grâce à Visual Web Developer.

IV.1.1.2. Visual C#

Visual C# est un outil de développement édité par Microsoft, permettant de concevoir des applications articulées autour du langage C#.

59

Visual C# propose les outils pour développer des applications C# hautement performantes qui ciblent la plateforme nouvelle génération de Microsoft pour la programmation distribuée et compatible Internet. Ce langage de programmation est simple, de type sécurisé et orienté objet. Il a été conçu pour générer des applications d'entreprise. Le code écrit en C# est compilé en code managé exécuté sous le Framework .NET.

IV.1.1.2. Microsoft SQL Server 2005

SQL Server 2005 est une base de données dite «de nouvelle génération». Elle propose des services qui vont de la gestion des données de l'entreprise aux services d'analyses en passant par la mise à disposition d'une infrastructure de développement.

D'un point de vue produit, cela se traduit par la disponibilité, dans SQL Server 2005, de différents modules ou services. Une installation de SQL Server 2005 sur un serveur donné peut mettre en oeuvre un, plusieurs, ou la totalité de ces services :

? le moteur relationnel composant assurant la gestion des données relationnelles de la base, la gestion des transactions, la sauvegarde, les différentes opérations de maintenance des bases de données relationnelles (sauvegarde, optimisation, organisation des tables et des index,...).

? les services de réplication fournit une réplication complète des modifications des schémas (ordres DDL), des fonctionnalités d'analyse novatrices, la réplication intégrée d'Oracle vers SQL Server.

? les services de notifications permettent aux entreprises de créer des applications de notifications complètes qui expédient vers n'importe quel système des informations personnalisées telles que les alertes de la bourse, les abonnements aux sites d'informations, les alertes de livraison de colis et les prix de billets d'avion;

? les services de reporting permettent la création complète d'une infrastructure de création, de gestion et de distribution de rapports. La partie création de rapports est assurée soit au travers de Visual Studio pour les développeurs, soit via Report Builder pour les utilisateurs finaux.

? les services d'analyses permettent la création, l'administration et l'utilisation de cubes multidimensionnels (technologies OLAP), de solution de Data Mining, la définition et l'exploitation d'indicateurs clés.

60

? les services d'intégration forment un ensemble d'outils graphiques et d'objets programmables que vous pouvez utiliser pour extraire, transformer et charger des données (scénario dit ETL - Extract Transform Load) et les déplacer vers une ou plusieurs destinations.

IV.1.1.4. Dia

Dia est un logiciel libre de création de diagramme développé en tant que partie du projet GNOME. Originellement conçu par Alexander Larsson, il est conçu pour servir des buts similaires au programme Visio de Microsoft et fait partie du projet GNU.

Dia est conçu de manière modulaire avec plusieurs paquetages de formes pour des besoins différents : diagramme de flux, diagramme de circuit électrique, diagramme UML, etc. L'ajout d'un paquetage se fait par l'écriture de fichiers XML, en utilisant un sous-ensemble du SVG pour dessiner les formes.

Il propose aussi la génération de code PHP5, C++, Java, Python, etc. directement depuis le diagramme UML fait dans DIA ou C# directement à partir des fichiers dia via l'utilitaire libre et gratuit.

Les points ci après soutient nos motivations aux outils présentés ci-dessus :

? Visual C# nous permet de pouvoir manipuler les classes lors de la programmation et la surcharge de méthodes et variables en nous évitant les pointeurs comme cela est requis en C++ et Java. Et de plus la disponibilité de Visual C# par rapport aux autres langages du fait de la popularité de produits Microsoft.

? Microsoft SQL Server supporte la manipulation d'un tas de données en local comme en réseaux. Et est doté des outils de sécurisation fiable au serveur de Base de données. ? Dia pour la facilité de production de modèle Orienté Objet.

IV.1.2.Implémentation de la base de données

Pour implémenter notre base des données «DanInfo_GesCom_Ohada», nous avons utilisé l'environnement de création de base des données SQL Server 2005.

61

IV.2. TEST DE L'APPLICATION

IV.2.1. Configuration matérielle requise

Pour tester notre application, la configuration minimale ci-dessous est nécessaire:

1. Ordinateur

L'ordinateur choisi doit être équipé d'un processeur cadencé à minimum 500 MHz et doit idéalement disposer d'un lecteur de CD ou DVD pour une installation locale. La résolution minimale de l'écran doit être de 1024 par 768. La mémoire doit être au minimum de 512 Mo et l?espace disque de libre +/- 5Go après installation du moteur de base de données. Notons que si le contrôleur de disque possède un cache matériel, il est important de le désactiver. SQL Server ne pourra garantir la cohérence et l'intégrité des données que si le contrôleur est désactivé, sauf si le contrôleur a été spécialement conçu pour une base de données. Enfin, les outils clients nécessitent Internet Explorer 6.0 ou une version ultérieure.

2. Système d'exploitation

Les systèmes minimums sur lesquels il est possible de tester notre application sont:

· W indows 2000 Service Pack 4;

Windows XP SP1;


·

· Windows Server 2003 en version 32 et 64 bits;

Avec Windows 2000 Professionnel Service Pack 4 et Windows XP Service Pack 1, il n'est possible d'installer que les éditions Express et Developer de SQL Server 2005. Sinon il faut aller vers Windows XP SP2, ...

Pour rappel, il est important de distinguer deux cas: d'un côté les plates-formes possibles pour le client et de l'autre les plates-formes pour le serveur, ces dernières sont reprises ci-dessus.

Parmi les plates-formes clientes, on peut distinguer:

· les postes sur lesquels les outils d'administration SQL Server 2005 peuvent être installés;

· les postes qui hébergent une application qui se connecte à une instance SQL Server 2005 pour gérer les données.

D'une façon synthétique, les outils clients d'administration peuvent être installés sur tous les systèmes d'exploitation Windows 2000, 2003, Windows XP Pro ou tout système plus récent (Vista, Win7...).

Dans le cas où le client héberge une application spécifique, la gamme des plates-formes est considérablement élargie grâce en particulier, au pilote jdbc qui permet d'accéder à

62

une instance SQL Server depuis une application écrite en Java. La gamme est encore élargie dans les cas d'une application aspx qui propose une interface web. Un simple navigateur permet alors d'accéder aux données.

3. Les droits d'accès

Les services exécutant chaque instance de SQL Server utilisent un compte de service. Ce dernier doit être choisi avec soin pour éviter d'éventuelles failles de sécurités sur le serveur.

SQL Server s'appuie par défaut sur le système d'authentification de Windows (Kerberos ou Natif). On peut donner des droits sur les différents éléments de SQL Server à un groupe ou à un utilisateur. Lors de la connexion à la base de données, l'utilisateur est identifié grâce à son login Windows et accède aux ressources de la base de données auxquelles l'administrateur lui a donné droit par l'intermédiaire de son groupe Windows ou directement à son identifiant. Lors de l'accès à une ressource extérieure, le processus SQL Server agit de 3 manières différentes : par emprunt d'identité lorsque la couche Windows est correctement configurée, l'utilisateur ne peut accéder par l'intermédiaire de SQL Server qu'aux ressources auxquelles il aurait droit s'il y accédait directement ; par le compte de service de l'instance, lorsque l'utilisateur est sysadmin et pour certaines tâches ; il ne permet pas l'accès, dans tous les autres cas.

Comme il existe des cas où l'utilisateur ne peut pas être identifié par son login Windows (utilisation de Linux, d'une page Web...) une méthode d'identification directe à SQL Server peut être mise en place. Elle doit l'être explicitement par l'administrateur de l'instance. Lorsqu'il accède à une ressource extérieure le processus SQL Server agit de 2 manières différentes, par le compte de service de l'instance, lorsque l'utilisateur est sysadmin et pour certaines tâches ; il ne permet pas l'accès, dans tous les autres cas.

Lorsqu'un utilisateur est connecté à une instance, il peut disposer de droits sur l'instance elle-même et/ou sur chacune des bases gérées par l'instance. Les droits sur l'instance sont donnés par l'intermédiaire de rôles d'instance prédéfinis. Les droits sur les bases de données sont donnés par l'intermédiaire de rôle de base de données, de groupes windows ou directement à l'utilisateur. L'espace utilisateur par défaut des administrateurs d'une base de données est dbo (database owner).

Il existe au niveau des bases de données des rôle applicatifs auxquels on peut affecter des droits et accessibles par mot de passe. Lorsqu'ils sont utilisés ils remplacent les droits de

63

l'utilisateur courant par les droits affectés au rôle. Ils sont utilisés pour interdire l'accès aux utilisateurs à une base de données par d'autres moyens que l'application qui leur est fournie.

IV.2.2. Tests unitaires

Ces tests permettent de vérifier individuellement que chaque sous-ensemble du

logiciel est implémenté conformément aux spécifications. En effet, Pour tester notre application nous avons sélectionné les données que nous jugeons représentatives des situations cernées dans notre travail. Cette activité consiste à tester les résultats de l'implémentation pour s'assurer du bon déroulement des fonctionnalités du système.

IV.2.2.1 Test du cas d'utilisation « Authentification »

A. Données types

L'utilisateur fournit au système le login et mot de passe et valide les données par le

bouton connexion.

Pseudo (code user) : fred

Mot de passe : fred

B. Résultats obtenus

Le système ouvre le menu général de l'application avec tous les sous menus.

C. Analyse et discussion des résultats

Le login et mot de passe doivent préalablement exister dans la base de données.

Si l'utilisateur entre un mot de passe qui n'existe pas dans la base, le système lui demandera le mot de passe jusqu'à ce qu'il entre le bon. Mais au cas où il entre un login sans respecter la casse, le système n'activera pas l'application et par conséquent les me nus ne seront que désactivés.



Figure 21 : Formulaire de connexion à l'application pour le cas d'utilisation
« authentification »

64

IV.2.2.3. Test du cas d'utilisation « Ajouter un utilisateur »

A. Données types

L'administrateur est le seul à ajouter les utilisateurs, sur ce il fournit au système le code de l'utilisateur, le nom, le sexe, l'adresse, le droit ou autorisation, le pseudo et mot de passe.

Numéro	Nom	Postnom	Sexe	Adresse	Droits	Pseudo		MotPass	GES003
Maliro	Fabrice	Masculin	Butembo	Lecture	Fab	Fab1072

Tableau 2:Données test pour le cas d'utilisation « ajouter un utilisateur »

B. Résultats obtenus



Figure 22:Capture d'écran du résultat d'ajout d'un utilisateur

Lorsqu'il clique sur sauver, le système lui affiche dans un datagrid les données qu'il vient de saisir et s'il désir les modifier ou supprimer, les recettes y relatives sont déjà prévues.

C. Analyse et discussion des résultats

Le système sauvegarde dans la base de données les informations saisies et affiche leur aperçu à chaque fois qu'il charge ce formulaire. Le numéro du gestionnaire est unique, aucune duplication n'est permise sinon un message d'erreur.

65

IV.2.2.4 Test du cas d'utilisation « éditer une facture de vente »

A. Données types

Le système par le truchement du formulaire de ventes demande à l'utilisateur logué de fournir les éléments ci après :

Numéro vente	Date vente	Réf.facture client	Code produit	Code tva	CodEx	Prix vente	Qte vendue
V001	26/07/2011	FAC004	31110000	T70V	2011	700	4
V001	26/07/2011	FAC004	31130000	T70V	2011	50	2
V002	26/07/2011	FAC004	31120000	T70V	2011	900	10

Tableau 3 : Données test pour le cas d'utilisation « éditer une facture de ventes »

B. Résultats obtenus

L'impression des éléments ci-dessus sera faite sur du papier en y ajoutant le Total Hors Taxe, Toutes Taxes Comprises, Tva pour chaque ligne de vente en cumul.



Figure 23 : Capture d'écran du résultat de l'application de l'impression d'une facture de vente

C. Analyse et discussion des résultats

Pour éditer une facture de vente, le système doit vérifier d'abord si le client, le produit, l'exercice, le bon de commande attaché à la facture, le Taux de Tva existent préalablement, sinon l'édition de la facture ne sera effective. Et cette recherche se fait par les listes de choix faisant remarquer l'existence d'un élément. L'on peut saisir dans la liste voulant éditer la facture de vente avec les données non réelles, le système par les contraintes d'intégrité et de référence signalera une erreur.

66

IV.2.2.5 Test du cas d'utilisation « imputer compte »

A. Données types

Le comptable désir imputer un compte :

Les données à priori sont les comptes, l'exercice, la monnaie, le comptable

NumOp	DateOp	Libelle	Taux	Monaie	Exercice	NumCble	PiecJ	MontDb		MontCred	0001
26/07/2011	Entrée Mses	800	FC	2011	C003	V001	100000	0		0001
26/07/2011	Variation de stocks Mses	800	FC	2011	C003	V001		100000

Tableau 4:Données Test du cas d'utilisation « imputer un compte »

B. Résultats obtenus



Figure 24:Capture d'écran du résultat de l'application du cas d'utilisation « imputer un compte »

C. Analyse et discussion des résultats

Lorsque le comptable veut imputer un compte, il y a de données qui devront exister au préalable. Le compte doit d'abord être créé et ensuite les opérations. Les comptes utilisés sont les comptes divisionnaires. Ces données permettront d'établir le bilan détaillé ou synthétique selon le besoin des utilisateurs. Si l'on a mal passé les opérations, il y a possibilité de les corriger. Mais également, il faudra faire attention lorsque l'on veut supprimer une opération car sa suppression se répercute sur les transactions. Dans la case débit ou crédit selon le cas, n'est pas oublier d'y mettre un nombre car celui-ci est requis, sinon, un message d'erreur sera générer.

67

IV.2.2.6 Test du cas d'utilisation « Ajout d'un nouvel article »

A. Données types

Le magasinier désir ajouter un article dans la base de données:

Code produit	Libelle produit	Description		CategorieProduit	31110000
Toshiba Satellite A10	CPU : 2Ghz, RAM :4Go, HDD : 200, SE: Win7...	Hardware		31000013
Windows Seven	Win7 Edition Professionel	Software		31000013
Dell Inspiron	CPU: 2Ghz, RAM: 2Go...	Hardware

Tableau 5 : Données test du cas d'utilisation « Ajout d'un nouvel article »

B. Résultats obtenus

La validation de données par le bouton sauver enregistre ces éléments dans la base de données.



Tableau 6: Capture d'écran du résultat de l'application du cas d'utilisation « Ajouter un nouvel

article »

C. Analyse et discussion des résultats

Le système devra vérifier si la catégorie du produit existe bel et bien afin de valider l'enregistrement. Sinon, un message d'erreur sera envoyé. La même chose se fera si l'on veut faire référence à une catégorie qui n'existe pas. Le système affiche en outre le pseudo ou le code de l'utilisateur logué pour raison de sécurité et contrôle.

68

IV.4. QUALIFICATION

Partant des objectifs nous assignés et des résultats de données obtenus lors de différents cas d'utilisation étant concluant, nous affirmons de ce fait notre hypothèse selon laquelle l'intégration de principes du génie logiciel dans la conception et développement du logiciel sur le modèle du SYSCOHADA aura un effet très positif sur l'efficacité et l'efficience du dit logiciel, de le réaliser dans les délais prévus, tout en satisfaisant le cahier des charges et qu'autrement ce logiciel s'inscrirait dans la catégorie de logiciel obsolètes .

Ainsi, demandons aux futurs utilisateurs de tester l'application et nous faire parvenir les remarques et bogues.

IV.5DOCUMENTATION

Nous présentons dans la suite, les informations nécessaires pour l'utilisation du

logiciel et pour des développements ultérieurs.

IV.5.1. Documentation orientée Programmeurs

Notre application est basée sous deux couches : physique (interface) et logique (librairie de classes). Ceci afin de répondre aux principes de séparation de problèmes, de modularité et réutilisabilité.

Toutes les grandes fonctions sont contenues dans une classe appelée Factory et elle nous permet d'accéder à d'autres classes. Les classes sont protéger et leur accès se fait par des accesseurs afin de respecter la règle d'encapsulation. Nous avons prévus de commentaires dans les sources de l'application afin que vous puissiez vous retrouver facilement.

IV.5.2. Documentation orientée Utilisateurs

Il est facile d'utiliser « DanInfo_GesCom_Ohada ». L'application a deux modules :

gestion de stock commercial et comptabilité.

Après son installation, l'utilisateur y accède par un login et mot de passe qui est « fred » et de même le mot de passe. Vous pouvez par la suite le changer selon vos besoins de sécurité.

Ensuite affiche les menus regroupés selon les taches à effectuées. Par exemple pour la gestion de stock, vous pouvez ajouter un utilisateur, le modifier ou supprimer. Pour les autres menus, il faudra s'assurer de la cohérence de données que vous souhaiter donner ou demander au système. Ainsi, vous ne pouvez pas imputer un compte dans le module de comptabilité si le compte n'existe pas c'est-à-dire avoir été créé.

69

En suivant aux lettres le manuel dans l'application vous vous familiariserez à celle-ci. Pour toutes bogues quelconques ou idées du futur amélioration de l'application, nous vos prions de prendre contact avec nous par les données de contacts se trouvant dans le menu aide Apropos de...

Conclusion : Dans ce chapitre, nous avons décrit brièvement le processus de réalisation de notre application « DanInfo_GesCom_Ohada » en spécifiant l'environnement de développement, l'implémentation de la base des données et la démarche suivie pour la réalisation. En effet, nous avons achevé l'implémentation et les tests de tous les cas d'utilisation, tout en respectant la conception élaborée. En d'autres termes, nous détenons la version finale du logiciel, installée dans notre environnement de développement. Ainsi que nous avons prévenu la plate forme sous laquelle le système sera installé dans l'environnement des utilisateurs.

70

CONCLUSION GENERALE

Sous le thème « Génie logiciel en Système Comptable Ohada : conception d'un logiciel de gestion de stock intégré à la comptabilité » , nous sommes partis de faits tels que les systèmes interactifs posent en général de nombreux problèmes d'utilisabilité, ne répondent pas toujours aux besoins des utilisateurs, sont mal adaptés à l'organisation du travail. Ensuite le problème de l'appropriation du code source, dont le vrai problème pour l'Afrique devient la mise en place de l'industrie logicielle destinée à tirer parti de l'ouverture de ce code, la cohabitation têtue avec des logiciels propriétaires (LP) et la résolution des problèmes de migration des LP vers des Logiciel Libre. Enfin, passant par la crise du logiciel et le coût trop élevé de ce dernier jusqu'au constant que les règles de l'industrie informatique regroupées dans ce que nous appelons communément « Génie Logiciel » doivent être mise en contribution pour l'intégration de l'OHADA dans l'informatisation des services du tissu économique congolais notamment la comptabilité.

Ainsi, la question à laquelle notre travail s'est proposé de répondre était de savoir quelles seraient les règles à appliquer pour intégrer en douceur l'OHADA dans les systèmes informatiques existants. En outre, que gagnons-nous en intégrant les principes du génie logiciel (impact) dans la conception et développement d'un logiciel et dans le cas échéant ce que nous perdons en le calquant sur le modèle du Système Comptable Ohada ?

Notre argumentation a stipulé que l'intégration de principes du génie logiciel dans la conception et développement du logiciel sur le modèle du SYSCOHADA aura un effet très positif sur l'efficacité et l'efficience du dit logiciel, de le réaliser dans les délais prévus, tout en satisfaisant le cahier des charges et qu'autrement ce logiciel s'inscrirait dans la catégorie de logiciel obsolètes !

Notre objectif général était de prouver qu'à travers les principes du génie logiciel, nous pouvions éviter le tabula rasa et que les logiciels existants peuvent migrer vers des systèmes plus complexes en moindre coût. Et plus en pratique choisir et appliquer les règles du Génie Logiciel aux logiciels de gestion de stock existant en comptabilité générale pour mettre en place un logiciel de gestion de stock respectant les normes comptables du SYSCOHADA.

Pour affirmer nos hypothèses nous avons utilisés la méthode documentaire pour une vision un peu plus large des éléments de doctrine ayant trait à notre objet d'étude. Le langage

71

de modélisation appelée « UML » pour Unified Modeling Language pour l'analyse de besoins et la conception de solutions et le langage de programmation C# 2008 pour mettre en place l'application en mix avec SQL Server 2005 pour les bases de données.

Nous avons ensuite analyser les existants afin de trouver plus ou moins un modèle qui nous a permis de simuler un travail qui devrait être fait dans une équipe de génie et nous a produit un logiciel de gestion de stock intégré à la comptabilité respectant les principes, méthodes et techniques du génie logiciel et la norme du système comptable Ohada.

L'application que nous avons produite ne traite que de certains aspects de la comptabilité générale liée au stock commercial. Elle est capable d'établir un bilan de situation, un journal des opérations, la balance de vérification, le grand livre, le bon de commande, bon d'entrée en stock, la fiche de stock, facture et autres documents. L'application n'avait pas comme objectifs de produire la fiche d'amortissement des immobilisations, l'établissement du TFR (étant facultatif), et les calculs de différents ratios.

Plusieurs modules peuvent facilement être ajoutés à ce squelette que nous venons de bâtir, prouvant ainsi que le génie logiciel peut nous dédouaner de plusieurs problèmes liés à la conception des grands systèmes. Le cas de la gestion de paie du personnel que nous avons modélisé en titre d'exemple pourra être ajouté facilement par les futurs chercheurs avec bien d'autres modules qu'ils pourront modéliser suivant les principes énoncés dans ce travail pour l'amélioration de la présente application.

72

BIBLIOGRAPHIE

I. OUVRAGES

1. Boris, M., Nanette, P., David, S., & Sébastien, T. (2004). Le droit uniforme africain des affaires issu de l'OHADA. Paris: Juris-Classeur.

2. Dobill, M. (2008). Comptabilité OHADA (éd. 2008, Vol. Tome 1). KARTHALA: Editions KARTHALA ET AEEC.

3. F a b i e n, P. i., & G e o f f, G. a. (2008). Avant- Propos. Dans De Tiny ERP à Open ERP: Pour une gestion d'entreprise efficace et intégrée. Paris: Groupe Eyrolles.

4. FONTAINE, M. (2006). Acte uniforme ohada sur le droit des contrats:Avant Projet. Louvain: UNIDROIT.

II. WEBOGRAPHIE

1. -. (s.d.). SYSCOHADA : Plan de comptes. Récupéré sur www.africa.africa.web-org.

2. Audibert, L. (2006). UML2. Consulté le Janvier 09, 2011, sur developpez.com: http://laurent-audiberpt.developpez.com/

3. wikipedia. (2011). Logiciel de Comptabilité. Consulté le Février 13, 2011, sur wikipedia: fr.wikipedia.org

4. Wikipedia. (2011). Petites et moyennes entreprises. Consulté le Février 13, 2011, sur wikipedia: fr.wikipedia.org

III. COURS

1. Balagizi, O. (2011). Cours. Questions Spéciales de Génie Logiciel . UNILUK.

2. Balagizi, O. (2011). Cours. Seminaire Informatique: Aspects Pratique de création de Base de Données . UNILUK.

3. J.P, S. K. (2011). Cours. Laboratoire Informatique II: C#.Net . UNILUK.

4. J.P, S. K. (2011). Cours. Questions Spéciales de Conception de Système d'Information:UML et Merise . UNILUK.

5. MASIVI, O. (2010). Cours. Génie Logiciel . UNILUK.

6. Tahé, S. (2008, Mai). Cours. Apprentissage du Langage C# 2008 et du Frame .Net 3.5 . Agers: Université d'Angers.

73

IV. MEMOIRES

1. Beller, R. (2006, Séptembre). Mémoire. Le logiciel libre : quelle opportunité pour les PME ? Metz: Université Paul Verlaine.

2. DARRAS, E. (2004, Septembre). Mémoire. Plans de migration de systèmes patrimoniaux vers des erp . LAVAL, QUEBEC: UNIVERSITÉ LAVAL.

3. James, K. M. (2009-2010, Octobre). Mémoire. Modélisation et le prototypage d'un progiciel adapté aux entreprises commerciales en ville de Butembo. . UNILUK.

4. Mchangama, I. ( 2006-2007). Mémoire. Conception et développement d'un logiciel de gestion commercial . Université de Monastir.

V. TRAVAUX DE FIN DE CYCLE

1. Freddy, K. N. (2009-2010, 0ctobre). TFC. Modélisation d'un système d'information informatisé et la conception d'une base de données de gestion du stock des Ets Tsang . UNILUK.

2. Fréderic, M. M. (2008-2009, Octobre). TFC. Formalisation Informatique de la comptabilité Hospitalière: cas de centre de santé . UNILUK.

VI. AUTRES

1. BERGER, A. (2008). Quel logiciel Pour votre système d'information. D o s s i e r t e c h n o l o g i q u e d e s P a y s d e S a v o i e , 1-4.

2. Emmanuel ADAM, C. K. (1999). Etude comparative de méthodes du Génie Logiciel en vue du développement les processus administratifs complexes. Génie Logiciel , pp. 40-54.

3. MAKELA, R. M. (2005). Modalités d'adhésion de la RDC au traité de l'Ohada. Kinshasa.

4. Ntambue-Tshimbulu, R. (2003). Logiciels libres et développement de l'Afrique : repenser la problématique. Dans Revue canadienne d'études de développement (Vol. Vol. XXIV).

5. Zambotto, C. (2008). L'organisation de la comptabilité dans l'entreprise.