Mise en place d’un système automatisé de pilotage ...

86
**************** DEPARTEMENT GESTION ************************** MEMOIRE DE MAÎTRISE ÈS SCIENCES DE GESTION Présenté et soutenu par : KOTO Joël Berthino Option : Informatique et Organisation Promotion : 2009 - 2010 Sous la direction de : « Mise en place d’un système automatisé de pilotage administratif dans une station de radiodiffusion FM » (Cas de Radio Voanio - Toamasina) Monsieur FARAJALLAH Fawzi Directeur de Radio Voanio TOAMASINA Encadreur Professionnel Monsieur RAHAJANIAINA Andriamasinoro Enseignant chercheur à l’Université de TOAMASINA Encadreur Enseignant UNIVERSITE DE TOAMASINA FACULTE DE DROIT, DES SCIENCES ECONOMIQUES ET DE GESTION Date de soutenance : 03 Mai 2012

Transcript of Mise en place d’un système automatisé de pilotage ...

****************

DEPARTEMENT GESTION

**************************

MEMOIRE DE MAÎTRISE ÈS SCIENCES DE GESTION

Présenté et soutenu par :

KOTO Joël Berthino

Option : Informatique et Organisation

Promotion : 2009 - 2010

Sous la direction de :

« Mise en place d’un système automatisé de pilotage

administratif dans une station de radiodiffusion FM »

(Cas de Radio Voanio - Toamasina)

Monsieur FARAJALLAH Fawzi

Directeur de Radio Voanio TOAMASINA

Encadreur Professionnel

Monsieur RAHAJANIAINA Andriamasinoro

Enseignant chercheur à l’Université de

TOAMASINA Encadreur Enseignant

UNIVERSITE DE TOAMASINA

FACULTE DE DROIT, DES SCIENCES ECONOMIQUES

ET DE GESTION

Date de soutenance : 03 Mai 2012

****************

DEPARTEMENT GESTION

**************************

MEMOIRE DE MAÎTRISE ÈS SCIENCES DE GESTION

Présenté et soutenu par :

KOTO Joël Berthino

Option : Informatique et Organisation

Promotion : 2009 - 2010

Sous la direction de :

« Mise en place d’un système automatisé de pilotage

administratif dans une station de radiodiffusion FM »

(Cas de Radio Voanio - Toamasina)

Monsieur FARAJALLAH Fawzi

Directeur de Radio Voanio TOAMASINA

Encadreur Professionnel

Monsieur RAHAJANIAINA Andriamasinoro

Enseignant chercheur à l’Université de

TOAMASINA Encadreur Enseignant

UNIVERSITE DE TOAMASINA

FACULTE DE DROIT, DES SCIENCES ECONOMIQUES

ET DE GESTION

Mai 2012

Sommaire

Remerciements ...................................................................................................................... 6

Liste des sigles, acronymes et abréviations ........................................................................... 7

Glossaire ................................................................................................................................ 8

Introduction ......................................................................................................................... 12

1. Historique et présentation de Radio Voanio .................................................................... 13

1.1. Présentation générale ................................................................................................ 15

1.1.1. Généralités de la radio ....................................................................................... 15

1.1.2. Historique et statut juridique ............................................................................. 15

1.1.3. Les missions radiophoniques ............................................................................. 16

1.1.4. Structure de la radio ........................................................................................... 16

1.1.5. Les obligations et règlementations .................................................................... 21

1.1.6. Les outils de gestion .......................................................................................... 21

1.2. Analyse des circuits du travail et présentation du projet .......................................... 26

1.2.1. Bilan de l’existant .............................................................................................. 26

1.2.2. Présentation du système..................................................................................... 27

1.2.3. Cahier des charges de l’application ................................................................... 27

2. UML et l’analyse des circuits de diffusion ...................................................................... 28

2. 1. Survol du langage UML .......................................................................................... 30

2.1.2. Présentation d’UML .......................................................................................... 30

2.1.3. Approche objet .................................................................................................. 33

2.1.4. Modélisation avec UML .................................................................................... 39

2. 2. Analyse des circuits ................................................................................................. 49

2.2.1. Principes ............................................................................................................ 49

2.2.2. Aspect statistique ............................................................................................... 50

2.2.3. Aspect fonctionnel ............................................................................................. 52

2.2.4. Cas d’utilisation ................................................................................................. 53

3. Mise en œuvre ................................................................................................................. 61

3.1. Conception ................................................................................................................ 63

3.1.1. Typologie des architectures ............................................................................... 63

3.1.2. Architecture générale de l’application ............................................................... 64

3.2. Réalisation ................................................................................................................ 65

3.2.1 Environnement de développement ..................................................................... 65

3.2.2. Application réalisée ........................................................................................... 65

3.2.3. Impacts du nouveau système ............................................................................. 71

3.2.4. Évaluation des coûts .......................................................................................... 71

Conclusion ........................................................................................................................... 73

Bibliographie ....................................................................................................................... 74

ANNEXES .......................................................................................................................... 76

Annexes 1. Besoins d’une radiodiffusion (cas de Radio Voanio) ................................... 77

Annexes 2. Présentation générale de l’OMERT .............................................................. 80

Annexes 3. Pouvoirs de l’OMERT .................................................................................. 81

Liste des figures ................................................................................................................... 82

Liste des tableaux ................................................................................................................ 83

Table des matières ............................................................................................................... 84

Remerciements

La réalisation de ce mémoire, qui couronne la fin du second cycle universitaire, n’a pu

être achevée sans la contribution de plusieurs personnes, auxquelles nous adressons nos

vives et sincères remerciements :

Monsieur RAHAJANIAINA Andriamasinoro, notre encadreur enseignant qui,

malgré ses lourdes responsabilités et diverses occupations, nous a transmis toutes

les recommandations et soutien pour la réalisation de ce document.

Monsieur FARAJALLAH Fawzi, notre encadreur professionnel, qui nous a dirigé

tout au long de l’élaboration de cet ouvrage.

Tous les enseignants du département « Gestion » de l’Université de Toamasina, qui

ont assuré notre formation. Sans leurs contributions, il nous aurait été impossible de

parvenir à ce stade.

Les enseignants de la Faculté de Droit, des Sciences Économiques et de Gestion à

l’Université de Toamasina, pour les enseignements dispensés durant nos études.

Particulièrement, nous ne saurions passer sous silence le dévouement de nos

CHERS PARENTS, qui nous ont toujours soutenus ainsi qu’à nos sœurs, frères et

toute notre famille. Nous vous dédions ce mémoire, en hommage aux efforts,

sacrifices et tout l’amour que vous nous avez toujours prodigué.

Radio Voanio et toute son équipe, qui nous a accueilli et éclairé nos connaissances,

Nous tenons aussi à remercier vivement tous ceux qui, de près ou de loin, nous ont

soutenu dans à l’achèvement de cet ouvrage.

Et tous nos amis étudiants pour leur chaleureux accueil et leur soutien indéfectible

durant les moments difficiles.

Merci infiniment.

Liste des sigles, acronymes et abréviations

CNaPS : Caisse National de Prévoyance Sociale

DEC : Digital Equipment Corporation

FC : Fiche Cabine

FM : Frequency Modulation

HP : Hewlett-Packard

HTML : HyperText Markup Language

IBM : International Business Machines corporation

IP : Internet Protocol

OOSE : Object Oriented Software Engineering

OMDA : Office Malagasy du Droit d'Auteur

OMERT : Office Malagasy d'Etudes et de Régulation des Télécommunications

OMG : Object Management Group

OMSI : Organisation Médico Sanitaire Inter-entreprise

OMT : Object Modeling Technique

PAD : Prêt A Diffuser

PME : Petite et Moyenne Entreprise

RAM : Random Access Memory

UML : Unified Modeling Langage

TCP : Transmission Control Protocol

Glossaire

Abstraction :

Les caractéristiques essentielles d’une entité qui la distinguent de toutes les autres

sortes d’entités. Une abstraction définit une limite relative du point de vue de

l’observation. Un modèle est une abstraction d’un seul système.

Acteur [Classe] :

Un ensemble cohérent de rôles que peut jouer un utilisateur des cas d’utilisation

lorsqu’il interagit avec ces derniers. Un acteur joue un seul rôle pour chaque cas

d’utilisation avec lequel il communique.

Agrégation (Aggregation) :

Une forme spéciale d’association qui spécifie une relation « tout-partie » entre

l’agrégat (le tout) et une partie.

Apache :

Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP produit

par l'Apache Software Foundation. C'est le serveur HTTP le plus populaire du Web.

C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache.

Attribut d’objet :

Caractéristique qui se rattache à un objet pour constituer sa forme et/ou sa structure.

Cas d’utilisation :

La spécification d’une séquence d’actions, incluant des variations, que le système (ou

une autre entité) peut exécuter, interagissant avec des acteurs du système.

Classe :

Entité destinée à regrouper des données à un type précis, sur lesquelles agissent un

ensemble de fonctions. Elle permet aussi de représenter des objets du monde réel.

Dans la pratique, c’est une implémentation d’un type, entité définie par un nom, un

schéma et une extension.

Collaboration :

La spécification de commentaire d’une classe (cas d’utilisation ou opération) est

réalisée par un ensemble de classeurs et d’associations jouant des rôles spécifiques.

Conception :

La partie du processus de développement logiciel dont le but principal est de décider

comment le système sera implémenté. Durant cette phase, des décisions stratégiques et

tactiques sont prises pour des besoins fonctionnels et qualitatifs du système.

Diagramme :

Représentation graphique d’une collection d’éléments de modélisation, le plus souvent

visualisée comme un graphe d’arcs (relations) ou de sommets (autres éléments de

modélisation).

Diagramme d’activité :

Cas particulier de diagramme d’états-transitions dans lequel tous les états (ou presque)

sont des états avec action, et dans lequel toutes les transitions (ou presque) sont

déclenchées par l’achèvement d’actions dans les états sources. Par opposition :

diagramme d’états-transitions.

Diagramme de classe :

Un diagramme qui montre un ensemble d’éléments de modélisation déclaratifs

(statiques), comme les classes, types avec leurs contenus et relations.

Diagramme de collaboration :

Un diagramme qui montre les interactions entre objets par une représentation des

objets et des liens qui les relient. A la différence d’un diagramme de séquence, le

diagramme de collaboration montre les relations entre les objets. Les diagrammes de

séquence et les diagrammes de collaboration montrent des informations similaires,

selon des points de vue différents mais de manières différentes.

Diagramme de composants :

Un diagramme qui montre les dépendances entre les composants.

Diagramme de déploiement :

Un diagramme qui montre la configuration des nœuds de traitement et les composants,

ainsi que les processus et les objets qui les accompagnent. Les composants

représentent les manifestations exécutables des unités de code.

Diagramme d’interaction :

Terme générique qui s’applique à différents types de diagrammes, qui mettent l’accent

sur les interactions entre objets, comprenant les diagrammes de collaboration, les

diagrammes de séquence et les diagrammes d’activités.

Diagramme de séquence :

Ce diagramme montre les interactions d’objet d’un point de vue temporel, en

particulier, les objets participants à l’interaction et la séquence des messages échangés.

Contrairement à un diagramme de collaboration, un diagramme de séquence inclut des

séquences temporelles mais ne montre pas de liens entre objets. Un diagramme de

séquence peut exister sous une forme générique (décrivant tous les scénarios

possibles) et sous une forme d’instance (qui décrit un scénario particulier).

Diagramme de cas d’utilisation :

Celui-ci montre les relations entre acteurs et cas d’utilisation dans un système.

Diagramme d’états-transitions :

Ce diagramme est un schéma qui permet de représenter des automates.

Diagramme d’objets :

Ce diagramme englobe les objets et leurs liens à un moment donné. Un diagramme

d’objet peut être considéré comme un cas particulier d’un diagramme de classe ou

d’un diagramme de collaboration.

Encapsulation :

Au niveau analyse, résultat de l’union des données et des traitements au sein d’une

même entité. Au niveau conceptuel, c’est le fait de cacher l’implémentation des

services offerts aux clients. Il s’agit du procédé permettant de « cacher » dans une

« capsule » les données d’un objet, de façon à ce qu’elles soient totalement inconnues

de l’extérieur. Ces données ne seront manipulées que par l’intermédiaire de méthodes,

appartenant à l’objet, également encapsulées.

Héritage :

Situation qui permet à une classe de dériver vers une autre classe. Cette sous-classe

hérite des propriétés publiques et protégées de la « super-classe ». L’héritage peut

modifier le comportement de certaines des méthodes héritées au niveau définition.

Interaction :

Une spécification du comportement qui comprend un ensemble d’échanges de

messages parmi un ensemble d’objets dans un contexte particulier dédié à une cause

spécifique. Une interaction peut être illustrée par un ou plusieurs scénarios.

Métamodèle :

C’est un modèle de langage de description de modèles. Métamodèle signifie

littéralement modèle du modèle. Il peut être défini comme la représentation d'un point

de vue particulier sur des modèles.

Modélisation :

Activité réalisée pendant la phase de modélisation de la démarche de développement

du logiciel. Elle inclut l’analyse et la conception et la phase d’exécution.

Objet :

Une entité avec une limite et une identité bien définie qui encapsule un état et un

comportement. L’état est représenté par des attributs et des relations, le comportement

est représenté par des opérations, des méthodes et des automates. Un objet est une

instance d’une classe.

Paquetage :

Un mécanisme général pour organiser des éléments dans un groupe. Les paquetages

peuvent être emboités les uns dans les autres. Un système peut être vu comme un seul

paquetage abstrait qui contient tout le reste.

PHP :

Langage de scripts libreprincipalement utilisé pour produire des pages Web

dynamiques via un serveur HTTP, mais pouvant également fonctionner comme

n'importe quel langage interprété de façon locale, en exécutant les programmes en

ligne de commande.

Propriété :

Une valeur normée qui dénote la caractéristique d’un élément. Une propriété a un

impact sémantique. Certaines propriétés sont prédéfinies dans le langage UML,

d’autres peuvent être définies par l’utilisateur.

Scénario :

Séquence spécifique d’actions qui illustre des comportements. Un Scénario peut être

soit une opération soit un signal.

Système :

Une collection d’unités connectées qui sont organisées afin d’atteindre un but

spécifique. Un système peut être décrit par un ou plusieurs modèles, éventuellement,

selon différents points de vue.

XAMPP :

XAMPP est un ensemble de logiciels permettant de mettre en place facilement un

serveur Web, un serveur FTP et un serveur de messagerie électronique. Il s'agit d'une

distribution de logiciels libres (X, Apache, MySQL, Perl, PHP, …) offrant une grande

souplesse d'utilisation et réputée pour son installation simple et rapide.

12

Introduction

Écouter la radio constitue un divertissement et demeure la première source

d'informations à Madagascar. Plus de 75% des foyers malgaches en possèdent et trouvent

qu'elle est indispensable1. Une utilité qui est d'autant plus prouvée pendant les saisons

cycloniques. Outre dans les foyers et les voitures privées, les transports collectifs (taxis, taxi-

be, taxis-brousse, pousse-pousse) s'approprient également de postes radio et optent pour la

station de leur choix, pour la satisfaction de leurs clients. A ceux-là, il faut ajouter les

restaurants, gargotes, bureaux, boutiques, marchés (bazar) et autres lieux publics.

Madagascar est leader en nombre de stations radios, parmi les pays de la région de

l'Océan Indien ainsi que ceux du continent Africain. La capitale malgache demeure le lieu de

concentration de la majorité (28%) de ces stations. On compte 253 stations radios à

Madagascar dont 13,4% sont à Toamasina. 2

Actuellement, une course sans fin s’installe. Les chanteurs et artistes essayent de

trouver des styles et rythmes nouveaux pour plaire aux amateurs. La radio diffusera ces

nouveautés afin d’attirer plus d’auditeurs et satisfaire les demandeurs. Cependant,

l’amélioration ne réside pas simplement dans les choix de diffusion ; mais devra se focaliser

davantage sur les aménagements internes, à la régie, afin de fidéliser et fortifier la relation de

confiance auprès des auditeurs. Ainsi, dans le présent mémoire, nous allons mettre en place un

système de pilotage administratif au sein d’une station radiodiffusion FM cas de Radio

Voanio Toamasina. La mise en place de ce système nous exige d’adopter la méthodologie de

travail suivante : d’abord, nous avons fait des enquêtes au niveau du personnel afin de pouvoir

analyser le fonctionnement interne de la station. Après, nous avons procédé à la mise en place

du système de pilotage proprement dit afin de surmonter les différentes failles rencontrées lors

de la phase d’analyse.

Ce mémoire se divise en trois parties : la première partie sera consacrée à la

présentation générale de la station et une analyse de circuit de travail pour comprendre la

problématique. Dans la deuxième partie, nous présenterons le langage UML et l’analyse des

circuits de diffusion et dans la dernière partie, nous verrons la mise en œuvre d’un système

automatisé de pilotage administratif.

1 Source : Extrait de www.madagascar-tribune.com, de février 2008 2 Source : Extrait de www.madagascar-tribune.com, de février 2008

13

1. Historique et présentation de Radio Voanio

14

L’objet de la première partie de l’étude est d’avoir un aperçu général de la

radiodiffusion. Nous allons, tout d’abord, présenter la Radio Voanio, et puis aborder les

passés et finalement, nous verrons les fonctionnements actuels de la Radio Voanio.

15

1.1. Présentation générale

1.1.1. Généralités de la radio

La radiodiffusion est l'émission de signaux par l'intermédiaire d'ondes électromagnétiques

destinées à être reçues directement par le public en général et s'applique à la fois à la réception

individuelle et à la réception communautaire. Ce service peut comprendre des émissions

sonores, des émissions de télévision ou d'autres genres d'émission.

Elle définit la transmission des sons : la voix humaine et les signaux audio par les ondes.

Dans un émetteur radiophonique, les sons sont transformés en signaux électriques basse

fréquence (signaux de modulation), ils sont superposés à une onde à haute fréquence (onde

porteuse) et, envoyés dans une antenne qui les transforme en ondes électromagnétiques.

Figure 1. Outils et processus de transmissions radiophoniques

Source : Document archive Radio Voanio, Support de communication mars 2002

1.1.2. Historique et statut juridique

La radio Voanio est la première radio à Modulation de Fréquence (FM) créée à Toamasina.

Sa fréquence est 98.2 Mhz, couvrant un rayon d’environs cinquante kilomètres autour de la

ville de Toamasina. La station de diffusion est basée au cœur de la ville, près du grand marché

(Bazar Be).

Elle est une radio de diffusion, Société à Responsabilité Limitée créée en septembre 2000

avec un capital de 2 400 000 Ariary. Elle a eu l’autorisation d’exploitation de la

16

radiodiffusion délivrée par le ministère de l’information de la culture et de la communication

à l’époque.

1.1.3. Les missions radiophoniques

Les actions et missions principales de la radio sont :

Faire divertir les gens de toutes générations, par des enchaînements de musiques,

des sketchs, des animations, des émissions, des jeux, etc.

Favoriser les égalités humanitaires, la liberté d’expression, les droits humanitaires.

Être à l’écoute des critiques, des propositions des sociétés pour transmettre au

responsable concerné.

Renforcer les éducations qui ont été instruites dans des établissements scolaires,

universitaires et dans les entreprises.

Informer sur les nouveautés et les actualités régionales, nationales et

internationales.

1.1.4. Structure de la radio

« Quelles que soient les variantes structurelles adoptées (fonctionnelles, décisionnelles, par

projets…), on observe toujours un phénomène de hiérarchisation dans les organisations. Cette

hiérarchie traduit des relations de pouvoir (du supérieur sur le subordonné) et correspond à

une division du travail de conduite de l’entreprise. Chaque cadre est en relation directe avec

un certain nombre de subordonnés et un ou plusieurs supérieurs. Le nombre de subordonnés

dépendant d’un supérieur définit une étendue de contrôle. Une structure est plus ou moins

plate selon la dimension de l’étendue de contrôle » disait Robert REIX dans « L’impact

organisationnel des nouvelles technologies de l’information ».

L’étude portant sur la structure de la société nous conduit à établir un organigramme de

structure des différents services fonctionnels ainsi que le diagramme d’attribution afin de

savoir «qui » fait « quoi ».

1.1.4.1. Organigramme

L’organigramme est la représentation schématique d’une structure de l’organisation.

Il permet à chacun de :

Connaître son rôle et l’étendue de ses fonctions et actions : Qui fait Quoi ?

17

Visualiser les niveaux hiérarchiques et les liens entre les fonctions et les interactions

des différents services afin d’éviter les erreurs ou omissions : dualité du

commandement, double emplois, outils de communication et d’analyse.

Actuellement, le nombre de fonctions est réduit, avec les outils informatiques qui se

chargent de beaucoup de services de façon automatique. Radio Voanio utilise des

équipements informatiques, par conséquent, son effectif est réduit, tout en diffusant jour et

nuit.

Figure 2. Organigramme fonctionnel hiérarchique

Source : Document archive Radio Voanio, Support administratif juin 2010

1.1.4.2. Les attributions des personnels

1.1.4.2.1. Directeur

Le Directeur assure le fonctionnement de l'entreprise et donne les grandes

orientations stratégiques, commerciales et marketing. Il est le premier responsable de la radio

tant au niveau technique qu’au niveau administratif. Dans le cadre des dispositions qui

régissent la gestion du personnel il prend toutes les décisions d'ordre individuel à travers des

définitions de règlement intérieur. Il peut déléguer, sous sa responsabilité, une partie de ses

pouvoirs au responsable de station.

1.1.4.2.2. Responsable station (Administration et Gestion)

C'est un poste de gestion administrative des différents services. Le responsable

supervise, organise et coordonne tous les services. Il est chargé de l'organisation et du

traitement des informations relatives à tous les personnels. Il joue fréquemment un rôle de

représentant auprès des instances administratives et professionnelles. Cette fonction nécessite

(1)Responsable Station

(1) Responsable Financier et Comptable

(3) Animateurs (1) Agent de sécurité

(4) Techniciens

(1) Agent de nettoyage

(1) Directeur

18

une grande disponibilité et des priorités à définir constamment. Pour ce poste et ces missions

le Responsable station :

Élabore et met en œuvre les moyens quantitatifs et qualitatifs (gestion de l'emploi,

recrutement, formation) nécessaires à une optimisation ou une adaptation des

ressources humaines aux finalités économiques de l'entreprise.

Assure la conduite de la gestion du personnel et l'application de la réglementation

sociale.

Est responsable de tout ou une partie de la politique de gestion courante et de

développement des ressources humaines.

Peut représenter la radio dans le cadre des relations avec les instances représentatives

du personnel et autres instances officielles.

Vérifie le fonctionnement et traite la maintenance des matériels.

1.1.4.2.3. Le Responsable Financier et Comptable

La comptabilité est une nécessité, tant officielle que pour le bon suivi des opérations

de l’entreprise. Elle permet de classer les dossiers de l’activité et de fournir les informations

utiles pour connaître la santé de l’entreprise. Avec les outils comptables, il est plus aisé de

faire ressortir les éléments obligatoires, répondant aux exigences réglementaires et d’alerter

les dirigeants de l’entreprise pour tous évènements importants. En fait, la comptabilité

collecte toutes les informations relatives aux opérations économiques réalisées par

l’entreprise, grâce aux documents qui les accompagnent (par exemple, une opération d'achat

ou de vente s'accompagnera toujours d'une facture). Ce sont ces « pièces comptables » qui

sont d’abord une obligation légale dans la gestion et surtout, un moyen de preuve en cas de

litige sur une opération figurant en comptabilité.

Le Responsable Financier et Comptable a la charge de préparer tous les documents

obligatoires et institutionnels pour l’administration fiscale, les organismes sociaux (CNaPS,

OMSI,…), etc. Il est chargé des relations avec les banques, les fournisseurs et les clients, dans

le cadre de la gestion financière. Il prépare les documents nécessaires aux règlements et

autres déclarations s’y afférents.

1.1.4.2.4. Technicien

Le rôle du technicien est d’accompagner les animateurs dans leurs émissions et peut

les remplacer, en cas de besoin. Le technicien est chargé des prises de son, des enchaînements

19

à l’antenne, du montage et autres travaux de production d’émission. Il est l’interlocuteur

direct auprès des auditeurs et collabore avec le responsable station. Ce poste exige :

La polyvalence;

La bonne connaissance du « terrain » : étendue de la ville et des parties avoisinantes ;

La maîtrise des « dialectes locaux » et plurilinguisme souhaité ;

La capacité de développer les contacts avec les auditeurs ;

Le charisme mais avec beaucoup de respect du public ;

La convivialité et chaleur d’accueil ;

Le respect de la déontologie de communication et réserve d’expression ;

L’exploitation rationnelle des équipements de studio et de reportage.

1.1.4.2.5. Animateur

L’animateur (appelé parfois présentateur), est l’acteur principal d’une émission,

selon une tranche horaire. Il présente des reportages, reçoit des invités, s’impose avec son

style et assure le bon déroulement de son émission, dans le respect des règles édictées par la

radio, mais aussi selon les exigences de la règlementation officielle.

Il doit connaître ses sujets afin de poser les bonnes questions pour que l’émission soit

vivante, dans l’objectif d’assurer une grande audience.

En liaison avec le responsable et le technicien, il conçoit le fil conducteur de

l’émission. Il travaille sur des documentations ou des entretiens préalables. Il imagine des

nouveaux concepts et apporte des nouvelles idées afin de diversifier ses interventions. Il doit

être dynamique et apte à s’adapter aux invités et aux sujets.

Pour les enregistrements, l’animateur peut les faire dans les studios de la radio. La

préparation de l'émission se fait généralement dans les bureaux de la station.

1.1.4.2.6. Agent de sécurité

Agent chargé de la surveillance et de la sécurité des matériels et des locaux de la

radio. Il surveille le respect des consignes relatives aux accès et autres mouvements

d’entrée/sortie. Il assure aussi le rôle de planton.

20

1.1.4.2.7. Agent de nettoyage

Personne chargée de l’entretien des locaux, respectant les règles de propreté et autres

tâches d’aménagement, pour l’accueil des clients et le bien être des salariés.

1.1.4.3. Le règlement intérieur

Radio Voanio procède à une restructuration de ses services et définit son

fonctionnement selon un règlement intérieur affiché, dont l’extrait est le suivant :

Le personnel doit toujours respecter la ponctualité (début et fin de chaque action).

Pendant l’exercice de sa fonction, une personne est soumise à l’ordre de la direction

de la radio.

Tous les contrats engageant la radio, établis par le chef de station, sont visés par la

direction.

Les informations sont affichées sur les tableaux d’affichage.

Le personnel peut à tout moment communiquer avec le chef de station.

Tous les personnels doivent respecter les dates et heures exactes de diffusion définies

dans la Fiche Cabine (FC).

Aucune diffusion ne peut se faire sans l’accord préalable du chef de station ou

supérieur hiérarchique.

Aucun document, support audio ou tout autre média ne pourra sortir de la radio,

quelque soit le motif, sans l’autorisation de la Direction.

Le personnel de la radio doit :

S’engager au « Devoir de réserve » et de confidentialité sur l’ensemble des

activités de la radio, pendant leur exercice et après la fin leur contrat ;

S’interdire de faire de sa fonction l’instrument d’une propagande quelconque ;

S’obliger à la « retenue » dans l’expression de ses opinions personnelles …

21

1.1.5. Les obligations et règlementations

1.1.5.1. Office Malagasy d'Études et de Régulation des Télécommunications1

L'Office Malagasy d'Études et de Régulation des Télécommunications (OMERT) est

l'entité de régulation du secteur des télécommunications à Madagascar. Il joue le rôle

d'incitateur et d'arbitre pour les opérateurs et veille au respect de la réglementation et des

droits des utilisateurs. Il assure le bon fonctionnement du secteur et met en œuvre la politique

gouvernementale de libre concurrence.

En revanche, la radio reçoit des factures bimestrielles pour la diffusion au publique.

1.1.5.2. Office Malgache de Droit d’Auteur2

L’Office Malgache de Droit d’Auteur (OMDA) est un organisme de perception et de

répartition de droits ainsi que la défense des intérêts matériels des auteurs et des ayants droits.

Pour la radiodiffusion, elle est en collaboration avec les artistes pour la diffusion des chansons

et des informations sur les nouveautés ; elle contribue et paie les droits d’auteurs à l’OMDA

tous les six mois.

1.1.6. Les outils de gestion

1.1.6.1. Personnel

En général, il rassemble les informations pour les diffusions. La Radio n’a pas besoin

beaucoup de personne pour son fonctionnement. Le personnel est chargé de faire des

animations et enregistrements d’émissions. La gestion du personnel est régulièrement assurée

par le Chef de station, qui détient et met à jour le dossier de chaque agent.

1.1.6.1.1. Le choix du personnel

La radio est une structure légère, disposant de ressources restreintes et conçue pour

être un outil de communication entre les mains de la population et au service de celle-ci. Elle

est aussi conçue pour les « Tamataviens » comme instrument d'information, d’éducation, de

sensibilisation, d’animation, etc.

1 http://www.omert.mg/, mai 2011 2 http://www.omda.mg/, mai 2011

22

La gestion des ressources humaines s’appuiera donc, dans le domaine de la radio, sur les

principes suivants :

L’effectif du personnel doit tenir compte des besoins réels.

Le bénévolat doit être évité, dans la mesure du possible.

L'évaluation du personnel doit être régulière.

1.1.6.1.2. Recrutement du personnel

Le besoin en personnel est exprimé par le Directeur ou le chef de station. Il décrit le

poste et le profil du candidat à rechercher. En cas de besoin, un avis de recrutement sera

annoncé à la radio même en précisant les pièces à fournir. Afin d’avoir le meilleur candidat à

l’admission, un test d’admissibilité sera organisé.

1.1.6.1.3. L’absence et le Congé

En cas d’absence d’un animateur, la rediffusion devient utile, pour combler un vide

dans la programmation.

1.1.6.1.4. La rémunération du personnel

La rémunération est conforme à la réglementation en vigueur ; toutefois, le personnel

de la radio sera rémunéré en rapport avec les revenus de la station. Elle est définie par rapport

à la qualité et la quantité du travail fourni par chaque agent dans le cadre de ses attributions

définies selon son contrat d’embauche.

1.1.6.1.5. Les bénévoles

Le bénévole est un membre de l’équipe qui met son savoir-faire, ses compétences et

son temps à la disposition de la radio pour contribuer à son épanouissement. En retour, il

n’attend aucune rémunération de la part de la radio.

C’est le responsable de la station avec ses collaborateurs (animateur et/ou technicien)

qui assurent leur encadrement. Chaque bénévole doit apposer sa signature sur une fiche

d’engagement. L’acceptation d’intervention d’un bénévole tient compte de ses capacités

d’intégration et d’adaptation au sein de l’équipe et ses compétences pour procurer un bon taux

d’audience. Une autre préoccupation sera de s’assurer de la moralité des intéressés. Le choix

sera aussi déterminé par la nature des besoins exprimés.

23

1.1.6.2. Programme de Diffusion

Afin de planifier la diffusion, il est important de connaître les cibles (enfants, jeunes,

parents, toutes générations, etc.) et les horaires (jours, heures) les plus pertinents pour

atteindre l’attention à l’écoute de la radio et faire passer les messages. Par ailleurs, certains

programmes de diffusions sont demandés par les auditeurs (chansons dédicacées, poésies,

horoscope, etc.) ; dans ces cas, l’horaire de la diffusion doit favoriser l’équilibre du taux

d’écoute. Ainsi, il y a des plages horaires qui sont réservées par le demandeur ou le client

pour la diffusion de sa publicité ou son message. La radio dispose d’un système de

programmation des dates et heures de toutes les diffusions de messages : la fiche cabine.

1.1.6.2.1. La fiche Cabine

La fiche cabine ou FC est une fiche de programmation de toutes les diffusions de

messages, annonces, publicités, etc. Cette fiche est représentée sous forme de liste, avec les

précisions de date et heure de la diffusion. La FC est préparée quotidiennement par le

responsable de la diffusion ou le responsable de la station. Grâce à cette fiche, l’animateur et

le technicien peuvent respecter le plan media demandé par le client.

1.1.6.3. Gestion du temps

Le temps est une donnée fixe, limitée. On ne peut, à sa guise, y ajouter ou enlever un

certain nombre d'heures. Par conséquent, il est important de gérer le temps le plus

efficacement possible afin d'en tirer le maximum de profit. Dans ce cas, comment gérer le

temps à la radio ?

En principe, seul le poste d’administration est un travail à temps plein (40 heures par

semaine) ; les autres postes étant variables selon les vacations. Chaque animateur dispose

d’un temps suffisant, régulièrement, pour effectuer ses recherches, dans le cadre de ses

thèmes ou émissions à préparer.

Pour cela, il est important de connaître, pour chaque animateur, le nombre d’heures

effectué par jour et par semaine, ainsi que les priorités du moment. Pour répondre à ces

questions, il est nécessaire d’établir une grille d’horaire du travail, organisée selon les besoins

du moment et respectant les principes généraux de la radio.

24

1.1.6.3.1. Grille de travail

C’est un tableau comportant les heures de début et fin du travail de chaque personnel,

pour tous les jours de la semaine. La grille est élaborée dans le respect des tâches prioritaires

de la journée ou de la semaine, mais également tenant compte des autres tâches.

Exemple1 : Grille des horaires de travail pour la journée de lundi

Animateur « A » : de 6 heures à 8 heures

Animateur « B » : de 8 heures à 12 heures

Animateur « C » : de 11 heures à 18 heures

Animateur « A » : de 18 heures à 20 heures

Tableau n°I. Grille des horaires

Heures 6h 7h 8h 9h 10h 11h 12h 13h 14h 15h 16h 17h 18h 19h

Animateur "A"

Animateur "B"

Animateur "C"

Animateur "A"

Programme Musical

Source : Document archive Radio Voanio, Support administratif juin 2010 (modifié)

1.1.6.4. Gestion du matériel

La gestion des ressources matérielles prend en compte plusieurs types d’opérations,

comme la gestion des immobilisations et la tenue des stocks.

La gestion du matériel est assurée par le responsable station, qui veille, également, à

l’exploitation et la maintenance des équipements. Chaque matériel est référencé sur la liste

des équipements. Les acquisitions, leur cession et leur mise au rebus se font avec l’accord de

la Directeur Générale. Chaque équipement et matériel roulant doivent avoir une fiche

d’entretien qui permet d’évaluer les efforts faits pour le maintenir en bon état. En outre,

chaque immobilisation doit être codifiée et marquée. A la fin de chaque année, le Responsable

de station procède à un inventaire physique du matériel.

La tenue des stocks est assurée par l'assistant gestionnaire. Il est tenu d’établir des

fiches de stocks et de les mettre à jour. Tous les trois mois, il fait parvenir au chef de station la

situation des stocks. Au moment de l’entrée de l’article en stock, il remplit le bordereau

d’entrée et met à jour sa fiche de stock. A chaque sortie d’article, il établit un bon de sortie et

met à jour la fiche de stock. Les originaux des bons de sortie et d’entrée sont envoyés au

comptable pour une tenue extracomptable. En fin d’année le chef de station et son équipe

25

procède à un inventaire physique des stocks, qui sera transmis au Responsable financier et

comptable.

1.1.6.5. Gestion commerciale

1.1.6.5.1. Gestion des achats

Les opérations telles que les factures reçues des fournisseurs et des prestations sont

enregistrées journellement. A la radio, il y a peu d’achat, essentiellement des fournitures de

bureau ou des équipements matériels.

1.1.6.5.2. Gestion des ventes

En principe, le client demande une facture pro forma, à la suite des échanges

commerciaux. Ensuite, il adresse un bon de commande à la radio. La facturation, suivie du

règlement, peut se faire avant ou après le service commandé, selon les accords définis au

préalable. Les factures sont souvent accompagnées d’un état des diffusions demandées par le

client (dans un plan media). Toutes les pièces constituant la gestion des ventes sont utiles pour

l’historique des opérations.

1.1.6.5.3. Marketing

Le marketing et les sondages sont faits sur le terrain lors de l’intervention ou

couverture médiatique. La diffusion de musiques, les animations, etc. forment une

composante nécessaire au marketing, pour l’élaboration de programmes variant les

informations, des styles et les orientations souhaitées par les auditeurs.

26

1.2. Analyse des circuits du travail et présentation du projet

1.2.1. Bilan de l’existant

1.2.1.1. Au niveau des achats et ventes/services

L’enregistrement des courriers, journal de caisse et la facturation sont faits

manuellement. Des doublons au niveau de numérotation des commandes, de l’arrivé de

courrier, de facture sont souvent rencontrés. Parfois, les calculs de somme présentent des

erreurs qu’il n’est plus fiable à la sortie de l’état ou de la situation de caisse ou/et facturation.

1.2.1.2. Au niveau Programme de diffusion

Les commandes de diffusion reçues sont saisies le jour de la réception de la commande

et sont vérifiées avant de les ressaisir dans la fiche de cabine ou le plan de diffusion.

La fiche cabine sort une journée avant la date de diffusion. Des erreurs de planification

sont rencontrées souvent surtout dans le cas de la diffusion à plusieurs fois. Et enfin, l’état de

diffusion (spot publicité, top Horaire, émission, etc.) est un moyen qui permet de faire le suivi

et le contrôle de la gestion des diffusions pour l’entreprise et le client alors que la méthode

manuelle actuelle ne les permet pas.

1.2.1.3. Au niveau Personnel

Pour équilibrer et de savoir le besoin en technicien et/ou animateur, un tableau de grille

de personnel est élaboré. Ce tableau présente le passage de chaque personnel à la radio pour

éviter une surcharge de personnel. Cependant, des confusions se présentent dans l’animation

ou/et dans la technique.

1.2.1.4. Au niveau du Temps de travail

Il est important, aussi de savoir le nombre de temps de travail effectif de chaque

personnel pendant son passage à la radio. Pour le moment, cette tâche est faite manuellement

et mérite une régularisation à chaque fin de mois.

1.2.1.5. Au niveau du Matériel

La radio dispose des équipements à jour. Mais l’enregistrement de ces matériels se fait

sur papier, ce qui complique la vérification et le traitement de l’inventaire.

27

1.2.2. Présentation du système

1.2.2.1. Objectif du système

L’objectif de notre système est d’automatiser la gestion de radiodiffusion. Il est possible

de concentrer les différentes opérations dans une base de données. En effet, pour qu’il soit

concurrentiel, l’entreprise devrait toujours améliorer le système de contrôle de gestion.

1.2.2.2. Intérêts du système

Les intérêts sont partagés entre l’entreprise et le client. Un résultat concret est

nécessaire pour faire l’analyse qui permet à l’entreprise de se développer dans le bon sens.

Le client doit être bien servi par rapport à sa demande. L’état et le journal de diffusion sont

disponibles, selon ses besoins ; ce qui permettra de fidéliser le client à l’entreprise.

1.2.3. Cahier des charges de l’application

Ce cahier des charges représente le résultat des spécifications des besoins du client, il est le

point d’entrée de l’analyse détaillée de l’application. On distingue le cahier des charges

fonctionnelles et le cahier des charges non fonctionnelles

1.2.3.1. Cahier des charges fonctionnelles

L’objectif du travail est de réaliser une application capable de gérer l’ensemble des

activités de la radiodiffusion.

1.2.3.2. Cahier des charges non fonctionnelles

Nous présentons dans cette partie les aspects du processus à suivre pour réaliser

l’application ainsi que les éléments de la qualité considérée lors de l’évaluation du logiciel.

La conception de notre application est basée sur le langage de modélisation UML. C’est

l’un des langages de modélisation objet le plus utilisé et compatible à tous langages de

programmation objet.

Cette partie nous permet de découvrir une brève historique et présentation de la Radio

Voanio. Pour la partie suivante, nous allons aborder la méthode d’analyse et l’analyse des

circuits de diffusions.

28

2. UML et l’analyse des circuits de diffusion

29

Dans cette deuxième partie nous présenterons la méthode d’analyse et de suivi des circuits

d’informations. Nous allons, parler de l’UML sans aborder les détails et d’analyser les

informations autour de la radiodiffusion.

30

2. 1. Survol du langage UML Ce chapitre est consacré à UML, il est composé de trois sections : une brève présentation du

langage, description de la notion d’objet et description des différents démarches de la

modélisation.

2.1.2. Présentation d’UML1

Nous présentons ici brièvement le langage de modélisation objet UML sans aborder tous

les principes ni en expliquer tous les détails, cette section permet d’aider à comprendre ce

langage.

UML (Unified Modeling Langage) qui peut se traduire par Langage de Modélisation Objet

Unifié, est né de la fusion des trois méthodes qui s’imposaient dans le domaine de la

modélisation objet au milieu des années 1990 : OMT2, Booch3 et OOSE4. D’importants

acteurs industriels (IBM, Microsoft, Oracle, DEC, HP, Rational, Unisys etc.) s’associent à

l’effort et proposent UML à l’OMG5 (Object Management Group) pour résoudre les

difficultés de mise en œuvre d’une approche « réellement objet ».UML est devenue une

norme OMG, en novembre 1997.

UML est un langage de modélisation objet. Il fournit les bases pour spécifier, construire,

visualiser et décrire les artefacts d’un système logiciel. Il se base surtout sur une sémantique

et sur une notation graphique expressive. UML défit les concepts de base et offre également

des mécanismes d’extension de ces concepts. Il permet d’exprimer et d’élaborer des modèles

objets, indépendamment de tout langage de programmation. Il a été pensé pour servir de

support à une analyse basée sur les concepts objets.

1http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML002.html, mars 2011. 2 OMT : Object Modeling Technique de James Rumbaugh, M. Blaha, W. Premerlani, F. Eddy 1991. 3 Booch ; Méthode de Grady Booch 1993 4 OOSE : Objet Oriented Software Engineering (appeleé aussi Objectory) de Yvar Jacobson 1992. 5 OMG est un organisme à but non lucratif, crée en 1989 à l’initiative de grandes sociétés (HP, Sun, Unisys,…)

pour promouvoir des standards qui garantissent l’interopérabilité entre application orientées objet, développées

sur des réseaux hétérogènes.

31

Figure 3. Historique d’UML

Source : http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML002.html

2.1.2.1. Les méthodes objets

La modélisation objet consiste à créer une représentation informatique des éléments du

monde réel auxquels on s’intéresse, sans se préoccuper de l’implémentation, ce qui signifie

indépendamment d’un langage de programmation. Il s’agit donc de déterminer les objets

présents et d’isoler leurs données et les fonctions qui les utilisent.

Une méthode objet est, d’une part, une méthode d’analyse du problème (afin de couvrir

toutes les facettes du problème) et, d’autre part, un langage permettant une représentation

IBM, Microsoft, Oracle, HP, Rational, Unisys, ObjecTime

Booch ‘91 G. Booch

OOSE I.Jacobson

Booch ‘93

UML 0.8

UML 0.9

UML 1.0

OMT - 1 J. Rumbaugh

UML 1.1

UML 1.3

Fragmentation

Unification

Standardisation OMG

Industrialisation

Octobre 95

Juillet 96

Janvier 97

Novembre 97

UML 2.4.1 Aout 2011

32

standard stricte des concepts abstraits (la modélisation) afin de constituer un langage

commun.

2.1.2.3. Les méthodes d’analyse et de conception

Une méthode définit une démarche reproductible qui fournit des résultats fiables. Une

méthode d’élaboration de logiciel décrit comment modéliser et construire des logiciels de

manière fiable et reproductible. Elle définit également des règles de mises en œuvre qui

décrivent l’articulation des différents points de vue, l’enchaînement des actions,

l’ordonnancement des taches et la répartition des responsabilités.

2.1.2.4. Caractéristiques1

UML est un moyen d’exprimer des méthodes objets en faisant abstraction de leur

implémentation, c'est-à-dire que le modèle fourni par UML est valable pour n’importe quel

langage de programmation. UML est un langage qui s’appuie sur un métamodèle, un modèle

de plus haut niveau qui définit les éléments d’UML (les concepts utilisables) et leur

sémantique (leur signification et leur mode d’utilisation).

2.1.2.4.1. Un modèle

Le modèle est une description abstraite d’un système ou d’un processus, une

représentation simplifiée qui permet de comprendre et de simuler. La modélisation n’est pas

un problème à solution unique. Bien souvent, le même problème analysé par des personnes

différentes conduit à des modèles différents.

2.1.2.4.2. Un métamodèle

Le métamodèle décrit de manière formelle les éléments de modélisation ainsi que la

syntaxe et la sémantique de la notation qui permet de les manipuler. Le gain d’abstraction

induit par la construction d’un métamodèle facilite l’identification d’éventuelles incohérences

et encourage la généricité.

Le métamodèle d’UML est un langage formel possédant les caractéristiques suivantes :

Un langage sans ambiguïtés

Un langage universel pouvant servir de support pour tout langage orienté objet,

Un moyen de définir la structure d’un programme, 1 Source : Rapport de stage de 2eme année de formation d’ingénieurs, février 2003, Sata DODO

33

Une représentation visuelle permettant la communication entre les acteurs d’un

même projet,

Une notation graphique simple, compréhensible même par des non informaticiens.

Le métamodèle permet de donner des bases solides et rigoureuses à ce langage, dont les

représentations graphiques servent, uniquement, à véhiculer des concepts de réalisation.

2.1.2.4.3. La modélisation

Le terme de modélisation est souvent employé comme synonyme d’analyse. C'est-à-

dire de décomposition en éléments simples, plus faciles à comprendre. La modélisation

fonctionnelle décomposition en éléments simples, plus facile à comprendre. La modélisation

objet décompose des systèmes en objets collaborant. Chaque métamodèle définit des éléments

de modélisation et des règles pour la composition de ces éléments de modélisation.

UML fournit un moyen astucieux permettant de représenter diverses projections

d’une même représentation grâce aux vues. Une vue est constitué d’un ou plusieurs

diagrammes. On distingue deux types de vues :

Vue statique : représentation physique du système

Les diagrammes d’objets ;

Les diagrammes de classe ;

Les diagrammes de cas d’utilisation ;

Les diagrammes de composants ;

Les diagrammes de déploiement

Vue dynamique : représentation du fonctionnement du système

Les diagrammes de séquence

Les diagrammes de collaboration

Les diagrammes états-transitions

Les diagrammes d’activités.

2.1.3. Approche objet

La programmation orientée objet consiste à modéliser en informatique un ensemble

d’éléments d’une partie du monde réel (que l’on appelle domaine) en un ensemble d’entités

informatiques. Ces entités sont appelées objets. Il s’agit de données informatiques regroupant

les principales caractéristiques des éléments du monde réel (taille, couleur, …).

34

Les spécificités de cette modélisation consistent à créer une représentation abstraite, sous

forme d’objets d’entités ayant une existence matérielle (chien, voiture, ampoule,…) ou bien

virtuelle (sécurité sociale, temps, …). Les objets informatiques définissent une représentation

abstraite des entités d’un monde réel ou virtuel, dans le but de les piloter ou de les simuler.

En UML, les objets se représentent au moyen d’icônes rectangulaires.

Figure 4. Objets

Source : auteur, novembre 2011

2.1.3.1. Modélisation d’un objet

La modélisation objet consiste à créer une représentation abstraite, sous forme d’objets,

d’entités ayant une existence matérielle (arbre, personne, téléphone,…) ou bien virtuelle

(sécurité sociale, compte bancaire, …). Un objet se caractérise par plusieurs notions :

2.1.3.1.1. Les attributions (propriétés)

Il s’agit des données caractérisant l’objet. Ce sont des variables stockant des

informations d’état de l’objet.

2.1.3.1.2. Les méthodes

Les méthodes d’un objet (appelées parfois fonctions membres) caractérisent son

comportement. Ces opérations permettent de faire réagir l’objet. De plus, les opérations sont

étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributions,

ou bien les modifier.

2.1.3.1.3. L’identité

L’objet possède une identité, qui permet de le distinguer des autres objets,

indépendamment de son état. On construit généralement cette identité grâce à un identifiant

naturellement du problème (par un numéro de série, …).

Id: Object0 Id: Object1

Id: Object2

35

UML propose une manière de représenter les objets de la façon graphique, sous forme de

rectangle, dans lequel le nom de l’objet est souligné.

2.1.3.2. Les liens entre objets

Dans l’approche objet, les objets ne sont pas des corps inertes isolés. Bien au contraire,

même s’ils possèdent leurs caractéristiques propres par l’intermédiaire des valeurs de leurs

attributions (ce qui constitue ce que l’on appelle l’état), ils ont la possibilité d’interagir entre

eux grâce à leurs méthodes. UML propose de représenter les liens qui existent entre les objets

grâce à un trait vis-à-vis d’un autre, c'est-à-dire lorsqu’un objet a un rapport directe avec un

autre (appartenance, utilisation, communication, …).

Il est possible d’ajouter des commentaires sur le modèle sous forme de notes. Une note

est représentée par un rectangle dont le coin supérieur droit est replié. Pour relier une note à

un objet il faut utiliser un trait discontinu (en pointillés).

Figure 5. Liens

Source : auteur, novembre 2011

2.1.3.3. Modélisation d’une classe1

On appelle classe la structure d’un objet, c'est-à-dire la déclaration de l’ensemble des

entités qui composeront un objet. Un objet est donc « issu » d’une classe, c’est le produit qui

sort d’un moule. En réalité on dit qu’un objet est une instanciation d’une classe, c’est la raison

1http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML002.html

Id: Object0 Id: Object1

Id: Object2 Lien

Note

36

pour laquelle on pourra parler indifféremment d’objet ou d’instance (éventuellement

d’occurrence).

Une classe est composée :

D’attributs : il s’agit des données, dont les valeurs représentent l’état de l’objet.

Des méthodes : il s’agit des opérations applicables aux objets.

Avec UML, une classe est présentée (voir figure 6) sous forme d’un rectangle divisé en

trois sections. La première section contient le nom donné à la classe (nom souligné). Les

attributions d’une classe sont définis par un nom, un type (éventuellement une valeur par

défaut, c’est à dire une valeur affectée à la propriété lors de l’instanciation) dans le second

compartiment. Les opérations sont répertoriées dans le troisième volet du rectangle.

Figure 6. Classe

Source : auteur, novembre 2011

2.1.3.3.1. Relation entre classe

Une association est une relation entre deux classes (association binaire) ou plus

(association n-aire), qui décrit les connexions structurelles entre leurs instances. Une

association indique, donc, qu’il peut y avoir des liens entre des instances des classes

associées.

Figure 7. Exemples d’associations

Association binaire Association n-aire

Source : http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML017.html

Classe

Document

Attributs

(ici, noms symboliques)

Client

id_client nom prenom adresse

Créer lister modifier supprimer

Méthode

(ici, noms symboliques)

37

Multiplicité ou cardinalité : La multiplicité associée à une terminaison d’association,

d’agrégation ou de composition déclare le nombre d’objets susceptibles d’occuper la

position définie par la terminaison. Voici quelques exemples de multiplicité.

Exactement un : 1 ou 1..1

Plusieurs : * ou 0..*

Au moins un : 1..*

De un à 5 : 1..5

Navigation : La navigabilité indique s’il est possible de traverser une association. On

représente graphiquement la navigabilité par une flèche du côté de la terminaison

navigable et on empêche la navigabilité par une croix du côté de la terminaison non

navigable. Par défaut, une association est navigable dans les deux sens.

2.1.3.3.2. La visibilité des attributs

L’un des principaux concepts du paradigme objet est l’encapsulation.

L’encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein

d’une structure en cachant l’implémentation de l’objet, c’est à dire en empêchant l’accès aux

données par un autre moyen que les services proposés. L’encapsulation permet donc de

garantir l’intégrité des données contenues dans l’objet.

En effet, la programmation orientée objet permet de cacher l’implémentation d’un

objet en ne lui permettant d’accéder aux attributs uniquement par l’intermédiaire de méthodes

crées à cet effet (on parle d’interface).

Il est ainsi possible de définir des niveaux d’encapsulation, afin de définir le type de

classe ayant accès aux attributs.

On parle de niveau de visibilité des éléments de la classe. Ces niveaux de visibilité

définissent les droits d’accès aux données selon que l’on y accède par une méthode de la

classe elle-même, d’une classe héritière, ou bien d’une classe quelconque. Il existe trois

niveaux de visibilité.

Publique : les fonctions de toutes les classes peuvent accéder aux données ou aux

méthodes d’une classe définie avec le niveau de visibilité public. Il s’agit du plus bas

niveau de protection des données (sécurité assez faible, presque inexistante).

38

Protégée : l’accès aux données est réservé aux méthodes des classes héritières, c'est-à-

dire par les fonctions membres de la classe ainsi que des classes dérivées (sécurité

moyenne).

Privée : l’accès aux données est limité aux méthodes de la classe elle-même. Il s’agit du

niveau de protection des données le plus élevé (sécurité très importante).

2.1.3.4. Les autres concepts importants de l’approche objet

2.1.3.4.1. L’héritage

C’est un mécanisme de transmission des propriétés d’une classe (ses attributs et

méthodes) vers une sous-classe. Une classe peut être spécialisée en d’autre classe, afin d’y

ajouter des caractéristiques spécifiques ou d’en adapter certaines. Plusieurs classes peuvent

être généralisées en une classe qui les factorise, afin de regrouper les caractéristiques

communes d’un ensemble de classes.

2.1.3.4.2. La spécialisation / la généralisation

La spécialisation et la généralisation permettent de construire des hiérarchies de

classes. L’héritage peut être simple ou multiple. L’héritage évite la duplication et encourage la

réutilisation.

2.1.3.4.3. Le Polymorphisme

Le polymorphisme représente la faculté d’une méthode à pouvoir s’appliquer à des

objets de classes différentes. Il augmente la généricité du code.

2.1.3.4.4. L’Agrégation

Il s’agit d’une relation entre deux classes, spécifiant que les objets d’une classe sont

des composants de l’autre classe. Une relation d’agrégation permet donc de définir des objets

composés par d’autres objets. L’agrégation permet d’assembler des objets de base, afin de

construire des objets plus complexes.

39

Figure 8. Hiérarchie de classes

Source : auteur, novembre 2011

2.1.4. Modélisation avec UML

2.1.4.1. Les démarches de l’élaboration de modèle

UML est un langage qui permet de représenter des modèles, mais il ne définit pas le

processus d’élaboration des modèles. Cependant, dans le cadre de la modélisation d’une

application informatique, les démarches sont les suivants :

Démarche itérative et incrémentale,

Démarche guidée par les besoins des utilisateurs du système,

Démarche centrée sur l’architecture logicielle.

2.1.4.1.1. Démarche itérative et incrémentale

L’idée est simple : pour modéliser (comprendre et représenter) un système complexe,

il vaut mieux s’y prendre en plusieurs fois, en affinant son analyse par étapes. Cette démarche

+ Oeuvre + Titre + Auteur

+ BD

+ Roman

Spécialisation

Généralisation

+ Opéra

+ Film

+ Livre

Relation d’héritage

40

devrait aussi s’appliquer au cycle de développement dans son ensemble, en favorisant le

prototypage.

Le but est de mieux maîtriser la part d’inconnus et d’incertitudes qui caractérisent les

systèmes complexes.

2.1.4.1.2. Démarche guidée par les besoins des utilisateurs du

système

La démarche de développement doit être pilotée par les cas d’utilisation. La

modélisation est guidée par l’identification des séquences d’évènements qui correspondent à

l’utilisation typique d’un système. La démarche montre que le système à construire se définit

d’abord avec les utilisateurs (capter les besoins). Cette approche permet un découpage du

développement par cas d’utilisation.

2.1.4.1.3. Démarche centrée sur l’architecture logicielle

La conception de l’architecture logicielle a pour objet de donner à un effort de

développement les moyens de parvenir à son but. L’architecture logicielle se préoccupe

d’intégrité, d’uniformité, de simplicité et d’esthétisme. Sa mise en place est la clé de voûte du

succès d’un développement. Il importe donc de la stabilité le plus tôt possible. La démarche

met en avant la préoccupation de l’architecture technique du système des travaux d’analyse.

Il est important de décrire une architecture type qui sera retenue pour le développement,

l’implantation et le déploiement.

Figure 9. Architecture d'UML

Source : auteur, novembre 2011

La vue logique décrit les aspects statiques et dynamiques d’un système en termes de

classes et d’objets et se concentre sur l’abstraction, l’encapsulation et l’uniformité. Elle met

en jeu les éléments de modélisation suivants :

Vue des processus

Vue logique

Vue de deploiement

Vue des composants Besoins des

utilisateurs

41

Les objets ;

Les classes ;

Les collaborations ;

Les interactions.

La vue des composants se préoccupe de l’organisation des modules statiques (les

exécutables, code source, etc.) dans l’environnement de développement. Elle montre

l’allocation des classes dans les modules et l’allocation des modules dans le sous-système.

Elle s’intéresse également à la gestion de configuration (auteurs, versions, …).

La vue des processus représente la décomposition en flots d’exécution (processus,

threads, tâche, …), la synchronisation des flots et l’allocation des objets et des classes au sein

des différentes flots. Elle se préoccupe également de la disponibilité du système, de la fiabilité

des applications et des performances. La vue des processus prend toute son importance dans

les environnements multitâches. Cette vue manipule les éléments de modélisation suivants :

Les objets actifs (les threads et les processus) ;

Les interactions ;

La vue de déploiement décrit les différentes ressources matérielles et l’implémentation

du logiciel dans ces ressources. Elle traite les points suivants :

Les temps de réponse et les performances du système ;

La bande passante des chemins de communication et les capacités ;

Les contraintes géographiques (disposition physique des processeurs) ;

Les besoins en puissance de calcul distribué ;

Les surcharges et l’équilibrage des charges dans un système distribué ;

La tolérance aux fautes et aux pannes.

La vue de déploiement prend toute son importance lorsque le système est distribué. Elle se

concentre sur les éléments de modélisation suivants : les nœuds et les instances de

composants.

La vue des cas d’utilisation forme la colle qui unifie les quatre vues précédentes. Les

cas d’utilisation motivent et justifient les choix d’architecture. Ils permettent d’identifier les

interfaces critiques ; ils obligent les concepteurs à se concentrer sur les problèmes concrets. Ils

démontrent et valident les autres vues d’architecture. La vue des cas d’utilisation rend compte

des éléments de modélisation suivants :

42

Les acteurs ;

Les cas d’utilisateur ;

Les classes ;

Les collaborations

2.1.4.2. Élaboration des modèles

UML opte pour l’élaboration des modèles, plutôt que pour approche qui impose une

barrière stricte entre analyse et conception. Les modèles d’analyse et de conceptions ne

différent que par leur niveau de détail, il n’y a pas de différence dans les concepts utilisés.

UML n’introduit pas d’éléments de modélisations propres à une activité (analyse,

conception, …) ; le langage reste le même à tous les niveaux d’abstraction. Cette approche

simplificatrice facilite le passage entre les niveaux d’abstraction. L’élaboration encourage une

approche non linéaire (les « retours en arrière » entre différents niveaux sont assurés par

l’unicité). La traçabilité entre modèles de niveau différents est assurée par l’unicité du

langage. Les différents niveaux d’abstraction sont : la conceptualisation, l’analyse du

domaine, l’analyse applicative et la conception.

2.1.4.2.1. Conceptualisation

L’entrée de l’analyse à ce niveau, est le dossier d’expression des besoins du client.

A ce niveau d’abstraction, on doit capturer les besoins principaux des utilisateurs. Il ne faut

pas chercher l’exhaustivité, mais clarifier, filtrer et organiser les besoins. Le modèle

conceptuel doit permettre une meilleure compréhension du système. Il doit servir d’interface

entre tous les acteurs du projet et joue un rôle central ; car il est capital de bien le définir.

2.1.4.2.2. Analyse du domaine

L’entrée de l’analyse à ce niveau, est le modèle des besoins clients (les cas

d’utilisation UML). Il s’agit de modéliser les éléments et mécanismes principaux du système.

On identifie les éléments du domaine, ainsi que les relations et interactions entre ces

éléments :

Les éléments du domaine sont liés au(x) métier(s) de l’entreprise,

Ils sont indispensables à la mission du système,

Ils gagnent à être réutilisés (ils représentent un savoir-faire).

43

A ce stade et selon des critères purement logiques, on organisera les éléments du domaine en

catégories :

Pour répartir les taches dans les équipes,

Regrouper ce qui peut être générique, etc.….

2.1.4.2.3. Analyse applicative

A ce niveau, on modélise les aspects informatiques du système, sans pour autant

rentrer dans les détails d’implémentations. Les relations entre les éléments des modèles et les

interfaces des éléments de modélisation sont définies. Les éléments de modélisations utilisés

peuvent être propres à une version du système.

2.1.4.2.4. Conception

Dans cette étape, on modélise tous les rouages d’implémentation et on détaille tous

les éléments de modélisations issus des niveaux supérieurs et les modèles sont optimisés, car

ils sont destinés à être implémentés.

2.1.4.3. Modélisation des vues statiques d’un système

2.1.4.3.1. Les cas d’utilisation

C’est l’ensemble d’actions réalisées par le système, en réponse à une action d’un

acteur. Les use cases peuvent être structurés, organisés en paquetages (packages). L’ensemble

des use cases décrit les objectifs (le but) du système. Les cas d’utilisation sont représentés par

des ellipses à l’intérieur desquelles figure le nom du cas d’utilisation (il peut être, également,

placé au-dessus d’ellipses). Les cas d’utilisations peuvent être contenus dans un rectangle qui

définit les limites du système. Les acteurs sont alors forcément à l’extérieur du rectangle

puisqu’ils ne font pas partie du système. Il est possible de préciser les comportements d’un

cas d’utilisation via du texte, de diagramme d’activités, de machines à état, de méthodes …

Les cas d’utilisation ou use cases permettent de :

présenter le fonctionnement du système vis-à-vis de l’utilisateur, c’est donc une vue

du système dans son environnement extérieur. Il s’agit de la solution UML pour

représenter le modèle conceptuel ;

structurer les besoins des utilisateurs et les objectifs correspondants d’un système ;

centrer l’expression des exigences du système sur ses utilisateurs ;

considérer que les objectifs du système sont tous motivés ;

44

identifier les utilisateurs du système (acteurs) et leurs interactions avec le système ;

classer les acteurs et structurer les objectifs du système.

2.1.4.3.1.1. Acteur

Cette entité externe agit sur le système (opérateur, autre système) et peut consulter ou

modifier l’état du système. En réponse à l’action, le système fournit un service qui correspond

à son besoin. Les acteurs peuvent être classés (hiérarchisés). Ils se présentent sous forme de

petits personnages ou via un symbole de classe avec le mot clé « acteur ».

Figure 10. Cas d'utilisation

Figure 11. Acteur

Source : auteur, décembre 2011

Il existe 4 grandes catégories d’acteurs :

Les acteurs principaux sont les personnes utilisant les fonctions principales du système.

Les acteurs secondaires sont les personnes qui effectuent des tâches administratives

ou de maintenance.

Le matériel externe regroupe les dispositifs matériels incontournables qui font partie

du domaine de l’application et qui doivent être utilisés. Il ne s’agit pas de

l’ordinateur sur lequel s’exécute l’application, mais des autres périphériques.

Les autres systèmes avec lesquels le système doit interagir.

2.1.4.3.1.2 Interaction entre l’acteur et le cas d’utilisation

C’est l’association entre acteur et cas d’utilisation qui peut contenir des multiplicités.

Use Case

Client

45

Figure 12. Interaction d'un système d’accès à la banque

Source : auteur, décembre 2011

2.1.4.3.2. Paquetages (Packages)

Les paquetages sont des éléments d’organisations des modèles. Ils regroupent des

éléments de modélisations, selon des critères purement logiques. Ils permettent d’encapsuler

des éléments de modélisations (ils possèdent une interface). Ils permettent de structurer un

système en catégories (vue logique) et sous-systèmes (vue des composants).

2.1.4.3.3. Diagramme d’objets

Ce type de diagramme UML montre des objets (instances de classes dans un état

particulier) et des liens (relations sémantiques) entre ces objets. Le diagramme d’objet est

utilisé pour montrer un contexte (avant ou après une interaction entre objets par exemple).

Il sert, essentiellement, en phase exploratoire car il possède un très haut niveau d’abstraction.

2.1.4.3.4. Diagramme des classes

Un diagramme de classe est une collection d’éléments de modélisations statiques, qui

montre la structure d’un modèle. Il fait abstraction des aspects dynamiques et temporels.

Retirer argent

Effectuer virement

Consulter comptes

Borne Interactive

d’une banque Classe Acteur

Association

Frontièrere du système

Client

Nom du système

Cas d’utilisation

46

Figure 13. Exemple: Diagramme de classe

Source : auteur, décembre 2011

2.1.4.3.5. Diagramme de déploiement

Les diagrammes de déploiement montrent la disposition physique des matériels qui

composent le système et la répartition des composants sur ces matériels. Ils correspondent à la

vue déploiement d’une architecture logicielle.

2.1.4.4. Modélisation des vues dynamiques d’un système1

2.1.4.4.1. Diagramme de collaboration

Les diagrammes de collaboration montrent les interactions entre objets en mettant

l’accent sur les relations entre un ensemble d’objets et de messages échangés (instances de

classes et acteurs). Ils permettent de représenter le contexte d’une interaction, car on peut y

préciser les états des objets qui interagissent.

2.1.4.4.2. Diagramme d’activités

UML permet de représenter graphiquement le comportement d’une méthode ou le

déroulement d’un cas d’utilisation, à l’aide de diagrammes d’activités (une variante des

diagrammes d’états-transition). Une activité est une exécution d’un mécanisme selon un

déroulement d’étapes séquentielles. Le passage d’une activité vers une autre est matérialisé

par une transition. En théorie, tous les mécanismes dynamiques pourraient être décrits par un

diagramme d’activités, mais seuls les mécanismes complexes ou intéressants méritent d’être

représentés.

1Sata DODO, Rapport de stage de 2ème année de formation d’ingénieurs, février 2003

habite

Entreprise

Maison Personne

travaille

Lien :

Relation entre objets (instance d’une

association entre instances de classes) qui

Définit une connexion sémantique.

Une personne travaille pour au plus

une entreprise et plusieurs personnes

travaillent pour une entreprise donnée.

1 *

1 . . 0

*

Cardinalités (multiplicités) : précise le nombre

d’instance qui participent à une relation.

47

2.1.4.4.3. Diagramme de séquence

Les diagrammes de séquences permettent de représenter des collaborations entre

objets selon un point de vue temporel, on y met l’accent sur la chronologie des envois de

messages. Contrairement au diagramme de collaboration, on n’y décrit pas le contexte ou

l’état des objets, la représentation se concentre sur l’expression des interactions. Ils peuvent

servir à illustrer un cas d’utilisation. Les diagrammes de séquences et diagramme d’états-

transitions sont les vues dynamique les plus importantes d’UML.

Figure 14. Diagramme de séquence

Source : auteur, décembre 2011

2.1.4.4.4. Diagramme d’états-transitions

Ce diagramme sert à représenter les automates d’états finis, sous forme de graphes

d’états, reliés par des arcs orientés qui décrivent les transitions. Les états-transitions

permettent de décrire les changements d’états d’un objet ou d’un composant, en réponse aux

interactions avec d’autres objets/composants ou avec des acteurs.

Acteur

un acteur

Id : Object

un objet

(une instance d’une classe)

ligne de vie

message simple

message

réflexif

réclusion

représentation graphique

d’un branchement

conditionnel

48

Comme UML n’impose pas de méthode de travail particulière, il peut être intégré à

n’importe quel processus de développement logiciel de manière transparente. UML est une

sorte de boite à outils, qui permet d’améliorer progressivement les méthodes de travail, tout

en préservant les modes de fonctionnement.

L’utilisation d’UML ne garantit pas le respect des concepts objet, mais on utilise ce

qui est nécessaire et approprié à la réalisation. Cependant il faudrait s’en servir à bon escient.

Intégrer UML dans un processus ne signifie donc pas révolutionner ses méthodes de travail,

mais serait l’occasion de se remettre en question, en s’inspirant des meilleures pratiques,

capitalisées à travers les processus unifiés.

49

2. 2. Analyse des circuits Des nombreux mouvements circulent dans la gestion de la radiodiffusion. Ce chapitre permet

de nous montrer tous les détails de ces circuits.

2.2.1. Principes

Les principes essentiels se composent de la réification, l’autonomie et la localité puis la

composition et l’affinage.

2.2.1.1. Réification

L’étude se focalise dans la gestion de radiodiffusion. L’analyse commence par la

commande d’un client, puis l’exécution de la diffusion du message et se termine par

l’encaissement de la facture correspondant aux services demandés. Cette gestion engendre

plusieurs mouvements qui sont difficiles à gérer manuellement.

2.2.1.2. Autonomie et localité

Le poste de gestionnaire est confié au chef station de la radiodiffusion. Ce poste

nécessite des moyens de travail suffisants, en plus des compétences, pour l’obtention de

résultats fiables.

2.2.1.3. Composition et affinage

La gestion de la radiodiffusion est composée de différentes opérations internes et

quelques mouvements externes.

Figure 15. Composition et affinage de la commande

Source : auteur, décembre 2011

Commande

Publicitaire Émission sponsorisée

Animation

Diffusion

Plan médias Plan médias Plan médias

Service

Animation externe

Montage Location studio

Plan médias Plan médias Plan médias

50

2.2.2. Aspect statistique

L’aspect statistique nous permet de visualiser l’ensemble des opérations par les objets. On

peut considérer, au départ, qu’il y a 6 objets :

Client

Commande

Animateur

Caisse

Facture

Article

Figure 16. Package

Source : auteur, décembre 2011

Séquencèrent des opérations

La radio propose aux clients des services de diffusions de publicités commerciales.

Le client contacte la radio, pour l’obtention des prix, pour les services souhaités.

Le client envoie sa Commande.

Le chef de station reçoit la commande.

Une fiche d’exécution du service est remise à l’animateur.

La diffusion est effectuée, par l’animateur.

Le chef de station établie la facture correspondant au service effectué.

La facture est envoyée au client.

Le client s’adresse à la caisse pour payer sa facture.

Client

Facture

Caisse

Animateur

Commande

Article

51

Figure 17. Diagramme de classe

Source : auteur, décembre 2011

Relation de cardinalité

Le client envoie une ou plusieurs commandes.

Une commande appartient à un et un seul client.

Une commande comporte un ou plusieurs articles (services publicités/annonces).

Un article appartient à une et seulement une commande.

L’article (service publicité/annonce) est diffusé une ou plusieurs fois par

l’animateur.

L’animateur diffuse une ou plusieurs fois la publicité/annonce.

La commande est facturée une fois seulement.

La facture est composée d’une et une seule commande.

La facture est encaissée une seule fois.

1

1..*

1..* 1..*

1..*

1

1 1..* 1 1..*

animateur anim_matricule anim_nom anim_prenom anim_adresse anim_contact anim_creer anim_modifier anim_liste

diffusion

diff_num diff_nombre diff_date diff_heure

diff_creer diff_modifier diff_annule

client client_num client_nom client_prenom client_adresse client_contact client_creer client_modifier client_liste

commande commande_num commande_date commande_creer commande_modifier commande_annule

facture

facture_num facture_date facture_creer factuer_annule factuer_imprime factuer_liste

caisse

caisse_code caise_mode caisse_mtt caisse_date caisse_encaisse caisse_decaisse

article

article_num article_ref article_design article_qte article_type article_creer article_modifier

prix prix_num prix_design prix_qte prix_mtt article_creer article_modifier

52

On encaisse une ou plusieurs factures.

2.2.3. Aspect fonctionnel

La première phase nous permet d’identifier immédiatement le premier acteur qui est le

chef station (responsable administratif). Il représente la Direction, selon les besoins, dans

certains domaines, tant au niveau interne que pour les représentations officielles. Il surveille

l’environnement interne et externe et particulièrement la partie administrative de la station.

Il prépare les contrats du personnel, les devis aux clients. Il reçoit et gère les courriers reçus

par la radio. Il traite les commandes des clients. Il prépare les « Fiches Cabines » de diffusions

des annonces, dédicaces, publicités et autres émissions demandées par les clients.

Il transmet à la cabine de diffusion les fiches quotidiennement, ainsi que le rapport de la

diffusion. La facturation sera faite par le chef station. Elle peut être faite avant ou après la

diffusion et de même pour le paiement ; selon la convention avec le client. Le chef station fait

la gestion de la caisse et l’enregistrement des mouvements financiers d’entrées et de sorties.

La deuxième phase nous amène à identifier un autre acteur qui apporte le mouvement à la

radiodiffusion. Le deuxième acteur est le client. Il commande des publicités et autres services

à la radio. Il dépose à la station le bon de commande avec le support à diffuser, lorsqu’il s’agit

de la diffusion. Il est possible, également, que le client demande l’intervention, dans ses

locaux, d’un animateur pour la préparation « sur terrain » du service à réaliser et la prise de la

commande (cas fréquent pour les clients qui habitent dans la ville de Toamasina). Pour les

autres clients, se trouvant à l’extérieur et loin du centre-ville, les échanges avec la radio se

font grâce aux courriers (papiers ou électroniques) et les confirmations seront faites par

téléphone. Les paiements sont fréquemment effectués par virement bancaire. Le nombre de

commande d’un client est illimité.

La troisième phase est l’identification de la personne qui s’occupe de la partie technique et

qui déclenche la diffusion. L’animateur est le troisième acteur. Après le traitement de la

commande par le chef station, c’est l’animateur qui exécute la demande de service, selon les

consignes et souhaits du client. Les animateurs ont la charge des animations et montages

audio. Généralement, il doit y avoir au moins un animateur à l’antenne.

La quatrième phase consiste à identifier les outils nécessaires à la réalisation des

diffusions. Pour ce faire, il faudra des sources audio (Ordinateur, lecteur CD, Microphone,

etc.) que nous considérons comme la quatrième acteur.

53

Enfin, l’émetteur en modulation de fréquence radio, couplé d’une antenne, est strictement

nécessaire pour la transmission à travers les ondes. Ce sera le cinquième acteur.

En résumé, on considère 5 acteurs autour de la gestion de la radiodiffusion :

Un chef station (responsable administratif)

Au moins un ou plusieurs clients

Au moins un ou plusieurs animateurs

Une ou plusieurs sources audio

Un émetteur (avec son antenne)

Figure 18. Diagramme de contexte statique

Source : auteur, décembre 2011

2.2.4. Cas d’utilisation

2.2.4.1. Identification des cas d’utilisation

Chef station

Recevoir les commandes

Préparer et envoyer la fiche cabine

Faire le rapport de diffusion

1..4 1..* Gestion de radiodiffusion

1

1 1..*

54

Établir la facture

Envoyer le courrier (facture et rapport de diffusion)

Encaisser la facture

Le client

Commande diffusion/service

Recevoir la facture

Recevoir le rapport de diffusion

Payer la facture

Animateur

Faire la technique

Diffuser les publicités ou autres services

Faire le montage audio ou autres services

Émetteur

Diffuser à travers les ondes.

Figure 19. Diagramme de cas d'utilisation

Source : auteur, décembre 2011

Gestion de radiodiffusion

Recevoir commande

Préparer/Générer fiche

cabine Faire la technique

Commander diffusion/Service

Diffuser la publicité

Faire montage/autres services

Faire le rapport de diffusion

Envoyer la facture/rapport

Payer la facture

Encaisser la facture

Recevoir la facture/rapport

Établir la facture

Client Animateur

Chef station

55

2.2.4.2. Acteur secondaire

L’acteur secondaire (l’émetteur et la source audio) complète le diagramme d’utilisation

préliminaire.

Figure 20. Acteur secondaire

Source : auteur, décembre 2011

2.2.4.3. Description textuelle du cas d’utilisation

Plusieurs mouvements sont enveloppés dans la gestion de la radiodiffusion. La plupart

des relations (voir figure 19) sont obligatoires. Les relations du chef de station, du client, de

l’animateur sont des relations qui doivent être respectées et exécutées, pour la continuité et la

gestion de la radiodiffusion.

Au départ, le client envoie ses commandes à la station radiodiffusion. C’est au chef de

station de gérer l’arrivée et l’envoi du courrier, il traite la Commande et l’envoie à la cabine

technique pour être diffusée ou à la cabine de montage. L’animateur exécute et diffuse le

message à partir des sources audio à travers les ondes grâce à l’émetteur et son antenne.

L’animateur s’occupe de la technique et fait le montage audio. Après la diffusion, le chef de

station établit un rapport de diffusion qui pourrait être demandé par le client, mais souvent

utile pour la traçabilité des opérations de gestion de la radio.

La facture établie par le chef de station est envoyée au client, avant ou après la diffusion

selon les conventions préalablement définies. Le client reçoit la facture, éventuellement avec

le rapport de diffusion. Il règle la facture qui sera constatée et encaissée par le chef de station.

2.2.4.3.1. Sommaire d’identification

Titre : Gestion de la radiodiffusion

Résumé : Le client Commande des services de publicités à la radio pour être diffusé

à l’antenne. Le chef de station et l’animateur prennent en charge la commande et

assurent la diffusion. Le chef de station établit la facture de la diffusion et assure la

gestion de caisse.

Animateur

Gestion de radiodiffusion

Faire la technique

Diffuser la publicité

Faire montage/autres services

56

Acteur :

Acteur principal : Chef de station, responsable de la gestion.

Acteurs secondaires : Les clients, animateurs, sources audio et émetteur sont

nécessaires et indispensables pour le bon fonctionnement général.

2.2.4.3.2. Pré-condition

Le client et le chef de station doivent établir une convention, appelée « plan media »,

qui devra définir les diffusions, facturation et règlement ; et qui sera respectée.

La commande du client doit arriver à la radio, au plus tard, deux jours avant le début

du plan média de diffusion.

La commande et la « fiche cabine » devront être traitées et envoyées à la cabine

technique, au plus tard, 24 heures avant l’heure de diffusion.

L’animateur respectera la date et l’heure de diffusion mentionnées dans la fiche

cabine et exécutera les instructions reçues de son supérieur hiérarchique.

Les sources audio et l’émetteur devront être opérationnels.

2.2.4.3.3. Scénario nominal

Tableau n°II. Présentation du partage de tâches entre les acteurs et le système

Utilisation, effectuée par Acteur Système

1. Le client commande des publicités et des services X

2. Le chef de station reçoit la commande X

3. Le chef de station traite la commande et établit la fiche cabine X

4. L’animateur réalise le montage audio X

5. L’animateur fait la technique et diffuse la publicité X

6. Le chef de station établit la facture X

7. Le chef de station fait le rapport de diffusion X

8. Le chef de station envoie au client : facture et rapport de diffusion X

9. Le client reçoit la facture et le rapport de la diffusion X

10. Le client paye la facture X

11. Le chef de station encaisse la facture X

12. Si le client n’est pas solvable, recours à la justice X

Source : auteur, décembre 2011

57

2.2.4.3.4. Scénario alternatif

Modification de la commande (ajout ou retrait de certains éléments), demandée par le

client.

L’enchaînement reprend au point 3 du Tableau n° II :

3 : Le chef de station met à jour la fiche cabine ;

4 : Le chef de station envoie la nouvelle fiche cabine à l’antenne ;

Ce cas est résolu en interne, sans aucune intervention auprès du client.

2.2.4.3.5. Enchaînement d’erreurs

Cas E1 : Annulation de la diffusion.

Cet enchainement peut démarrer à partir du point 3 jusqu’au point 8. Le chef de

station annule l’ensemble des diffusions prévues et le cas d’utilisation se termine par un

échec.

Cas E2 : Coupure de courant pendant la diffusion.

Cet enchainement démarre à partir du point 4 jusqu’au point 8 du scénario nominal.

L’animateur arrêtera tous les équipements, pendant la coupure. La reprise

s’effectuera après le rétablissement du courant électrique.

Cas E3 : Le client n’est pas solvable.

L’enchainement de ce cas démarre au point 10 jusqu’au point 12 du scénario

nominal.

2.2.4.3.6. Post-condition

Le chef de station et les animateurs sont engagés vis-à-vis de la station

radiodiffusion.

Toutes les données se rapportant aux clients, utiles à l’activité, sont soigneusement

enregistrées dans les dossiers clients.

Les historiques et archives, de toutes natures, sont classés par catégorie et par année.

2.2.4.4. Description graphique du cas d’utilisation

La description textuelle du cas d’utilisation est, non-seulement utile, mais nécessaire

pour permettre aux acteurs de communiquer entre eux plus facilement utilisant la bonne

terminologie et clarifiant la situation concernée.

58

En revanche, la forme textuelle présente quelques inconvénients, car il est parfois

difficile d’expliquer certaines successions d’enchaînements, ou à quel moment les acteurs

secondaires sont sollicités. Par conséquent, il est essentiel de compléter la description

textuelle par un ou plusieurs diagrammes dynamiques d’UML.

Figure 21. Diagramme des activités

Source : auteur, janvier 2012

Act

ivit

é 1

Act

ivit

é 2

Act

ivit

é 3

Commande Recevoir des commandes

Facturation

Préparation et génère la FC

Diffusion à l’antenne Technique / Montage Animation à l’extérieur

Rapport de diffusion ou d’activité

Envoie des courriers

Encaissement

Début

[Commande annulé]

flot

Fin

59

Figure 22. Diagramme de séquence à la réception de la commande

Source : auteur, février 2012

Figure 23. Diagramme de séquence de préparation et la diffusion

Source : auteur, février 2012

Figure 24. Diagramme de séquence de rapport de diffusion et de facturation

Source : auteur, février 2012

Client Chef station Système

Envoie la commande

Génère la FC

Prépare la FC

Chef station Système Animateur

Envoie la FC

Émetteur

/ Source audio

Faire le montage

Faire la diffusion

Faire l’animation

Envoie rapport et facture

Demande de facture

Client Chef station Système

Génère le rapport de diffusion

Génère la facture

Rapport de diffusion imprimé

Demande de rapport de diffusion

Facture imprimée

60

Figure 25. Diagramme de séquence d'encaissement de la facture

Source : auteur, février 2012

Cette deuxième partie nous a éclairé le fonctionnement de la diffusion par des analyses

des circuits de diffusion. Nous allons mettre en œuvre cette analyse dans la troisième et

dernière partie de cet ouvrage.

Mettre à jour la caisse

Client Chef station Système

L’information se met à jours

Paye la facture

61

3. Mise en œuvre

62

Cette troisième et dernière partie sera consacrée à la mise en œuvre de notre projet.

Nous commençons par la conception et puis la réalisation proprement dit et enfin nous

évoquerons les impacts de ce nouveau système.

63

3.1. Conception

3.1.1. Typologie des architectures

Pour développer un logiciel, le choix de l’architecture d’application est une étape

incontournable. Dans notre cas, nous avons choisi d’utiliser l’architecture client/serveur car

c’est la plus appropriée. L’aspect commun de toutes les applications client/serveur, quelque

soit le type choisi, est que les données nécessaires à l’utilisation du système d’information

sont localisées au niveau du serveur. Il existe deux scénarios possibles pour ce genre

d’architecture : scénario à deux niveaux et scénario à trois niveaux.

3.1.1.1. Scénario à deux niveaux

Ce type d’architecture est facile à mettre en œuvre, il est extensible mais possède des

limitations. En effet, il est difficile de distinguer l’indépendance entre l’interface utilisateur et

les traitements fonctionnels, et ceci empêche l’évolution de l’application et sa réutilisation.

De plus, il est difficile de modifier la structure de la source de données puisqu’elle est très liée

à l’interface utilisateur. Aussi, il est difficile de remplacer la couche du logiciel. Malgré ces

inconvénients, cette architecture peut être mise en place aisément dans un cadre de gestion

pour une PME.

Figure 26. Architecture à deux niveaux

Source : auteur, février 2012

3.1.1.2. Scénario à trois niveaux

Cette architecture constitue la base des futures applications distribuées grâce à

l’indépendance des différentes couches du logiciel. En effet, elle supprime tous les

inconvénients précédents. Sur les postes (ou système) clients, on ne trouve que les codes de

Base de données

Système Client

Système Client

64

l’interface graphique. Par ailleurs, les traitements et les données se trouvent sur le serveur qui

permet de :

Minimiser le code du coté client,

Élargir l’architecture en répartissant le code sur d’autres serveurs,

Traiter (modifier) indépendamment le code fonctionnel, le code de présentation et les

sources de données

Figure 27. Architecture à trois niveaux

Source : auteur, février 2012

3.1.2. Architecture générale de l’application

Le choix d’une architecture système ne fait pas partie du domaine de compétence de

l’UML, c’est pourquoi nous présenterons dans cette section l’architecture générale de

l’application d’après les spécifications techniques données par les clients. Cette architecture

est résumée par la figure 28.

Figure 28. Architecture générale de l'application

Source : auteur, février 2012

Chaque travail effectué par l’utilisateur (coté client) se caractérise par le remplissage de

formulaires. Les utilisations principales du client sont la saisie, la modification et

interrogation des données stockées dans la base de données. Ces tâches sont pilotées par

le serveur d’application. Les applications résident sur le serveur et permettent

l’enregistrement et le traitement des données ainsi que l’exécution des requêtes sollicitées par

le client.

Médiateur d’accès aux

données

Base de données Application Serveur

Enregistrement des données.

Traitement de requête.

Application Client

Formulaire de saisie et modification

Interrogation

Base de données

Système Client

Système Client

Serveur d’application

65

3.2. Réalisation Ce chapitre est réservé à la réalisation de l’application. C’est dans ce chapitre que nous

allons découvrir l’environnement de développement, le langage choisi et l’application

réalisée.

3.2.1 Environnement de développement

Comme support de développement, notre choix s’est porté sur Xampp. Xampp est un

ensemble de logiciels permettant de mettre en place facilement un serveur Web, un serveur

FTP et un gestionnaire de base de données relationnelles. Il s'agit d'une distribution de

logiciels libres (X, Apache, MySQL, Perl, PHP) offrant une grande souplesse d'utilisation,

réputée pour son installation simple et rapide. Ainsi, il est à la portée d'un grand nombre de

personnes puisqu'il ne requiert pas de connaissances particulières et fonctionne, de plus, sur

les systèmes d'exploitation les plus répandus à savoir: Windows, Mac OS, GNU/Linux ce qui

le différencié avec d’autre environnement de développement : Wamp, easyPHP, etc.

Le langage PHP sera interprété par le serveur Web Apache dans l’environnement de

Xampp. Les données seront stockées dans une base de données MySQL, et gérées par des

codes SQL intégrés dans les codes PHP.

Nous avons utilisé NotePad+ pour la rédaction et le traitement des codes écrits en langage

PHP et ou en HTML.

L’implantation de la base de données, ainsi que son administration sont gérées par

l’environnement de Xampp, permettant toutes les opérations d’entrée/sortie et de pilotage de

la sécurité, nécessaire à la mise en place et l’utilisation par les postes clients.

3.2.2. Application réalisée

3.2.2.1 Installation et Configuration

Installation

L’installation de l’application se fait en deux étapes : on installe d’abord Xampp dans la

machine serveur et puis, on crée la base dans le serveur à l’aide des scripts (ensemble des

commandes en mysql) et on copie les fichiers nécessaires (codes sources d’extensions .html

et .php) dans le répertoire htdocs du répertoire d’installation de Xampp. Pars exemple dans

c:\Xammp\htdocs si l’on installe Xampp dans l’unité de disque C.

66

Configurations matérielles

Système d’exploitation : Windows 2000, XP, Vista et 7

Processeur : Pentium 4 minimum

Mémoire vive (RAM) : 512 Mégaoctet minimum

3.2.2.2 Les fonctionnalités du système Pour entrer dans le système, les règles de sécurité adoptées nécessitent l’identification

de l’utilisateur afin de protéger les informations. Seuls les utilisateurs authentifiés auront

l’accès. En cas d’erreur, un message sera affiché à l’écran pour informer l’utilisateur de

l’incohérence ou de l’erreur constatée (Identifiant inconnu, mot de passe incorrect, accès

dépassant la limite d’utilisation, etc.).

Figure 29. Erreur d'authentification : données obligatoires non saisies

Source : auteur, mars 2012

Figure 30. Erreur d'authentification : mot de passe incorrect

Source : auteur, mars 2012

67

Le menu principal de notre application est composé des éléments (sous menus) suivants :

Animateur

Client

Commande

Fiche cabine

État facture

3.2.2.2.1. « Animateur »

Ici, la liste des animateurs est affichée au premier plan (voir figure 31). Dans cette

liste, une ligne représente un enregistrement. La modification d’un enregistrement pourra se

faire en cliquant sur la ligne correspondante. Pour ajouter un nouvel enregistrement, il suffit

de cliquer sur le bouton nouveau qui se trouve en bas de page.

Figure 31. Liste des animateurs

Source : auteur, mars 2012

Le formulaire de modification se présente comme le formulaire de saisie d’un nouvel

enregistrement. La seule différence est que celui de la modification est rempli de données.

68

Figure 32. Formulaire de saisie Fiche animateur

Source : auteur, mars 2012

3.2.2.2.2. « Client »

L’activation du menu client affiche par défaut la liste des clients. La procédure de

modification est la même que celle qu’on a dans le menu animateur.

Figure 33. Liste des clients

Source : auteur, mars 2012

69

Figure 34. Formulaire de saisie Fiche Client : Création et modification

Source : auteur, mars 2012

3.2.2.2.3. « Commande »

Ce menu nous permet de :

Enregistrer et modifier les commandes passées par les clients ;

Avoir les rapports de diffusion et apporter des éventuelles modifications ;

Facturer les clients ;

Figure 35. Formulaire de la Commande

Source : auteur, mars 2012

70

3.2.2.2.4. « Fiche Cabine »

Le menu « Fiche cabine » regroupe toutes les dates de diffusion afin d’avoir un état

de la diffusion pour une date choisie.

Figure 36. Formulaire d'état fiche cabine

Source : auteur, mars 2012

3.2.2.2.5. « État Facture »

Le menu « État Facture » affiche la liste de toutes les factures avec leur solde. Ce

menu nous permet aussi d’encaisser les factures impayées et de visualiser la liste des factures

payées.

Figure 37. Formulaire d'état facture

Source : auteur, mars 2012

71

3.2.3. Impacts du nouveau système

3.2.3.1. Impacts internes

Il faut bien reconnaître que l’implantation de ce système de contrôle nécessite des

investissements et une réorganisation interne de l’entreprise, et d’apporter les réponses aux

attentes de la clientèle.

3.2.3.1.1. Au niveau du financement

La mise en place de ce système de contrôle de gestion demande un investissement

pour l’acquisition d’un ordinateur de bureau qui sera le serveur, et les frais divers.

3.2.3.1.2. Au niveau gestion administrative :

Grâce à l’automatisation du contrôle, les consultations, les états et des situations

récapitulatives seront accessibles par un simple clic.

La gestion, des clients et des employés, est effectuée en temps réel.

Les données sont en sécurité et disponibles à tout moment.

La rapidité des traitements de l’information constitue un atout pour les décisions.

La lisibilité des données obtenues et exploitation plus facile des résultats.

L’automatisation de nombreux traitements apporte des aides à la partie comptable.

Un gain de temps dans la réalisation des états de synthèse

3.2.3.2. Impacts externes

La satisfaction des clients favorisera leur fidélité.

L’image de l’entreprise est valorisée.

3.2.4. Évaluation des coûts

3.2.4.1. Coût de réalisation

Pour la réalisation de ce système de contrôle, on estime, c’est un travail de 60 jours d’un

prix de 150 000 Ariary par jour homme.

3.2.4.2. Coût d’installation

Le coût d’installation va se diviser en 2 parties :

72

L’acquisition d’une nouvelle machine pour le serveur de données : 900 000 Ariary.

Formation des employées : 200 000 Ariary.

La mise en réseau et tous les matériels de réseau n’est pas nécessaire, les ordinateurs de

la Radio Voanio sont déjà en réseau, ne reste que la configuration du réseau de la nouvelle

ordinateur.

Tableau n°III. Récapitulatif des coûts

Coûts Montant (Ariary)

Réalisation 9 000 000 Ariary

Installation 900 000 Ariary

Formation pendant 7 jours 200 000 Ariary

Total 10 100 000 Ariary

Source : auteur, mars 2012

Les interventions à l’occasion de problèmes techniques constatés et la mise à jour des

programmes ne sont pas incluses dans les coûts de réalisation et d’installation.

73

Conclusion

Dans l’ère de la numérisation, notre XXIème siècle, l’automatisation est devenue

un sujet ordinaire ainsi que son déploiement et sa vulgarisation. Cependant, automatisation

rime avec organisation et essentiellement lorsqu’il s’agit de l’architecture des données, ainsi

que les applications développées à mettre en place. De plus, chaque étude d’automatisation

nécessite un soin spécifique, pour l’accomplissement des développements de logiciels

et de leur architecture. Ces tâches sont souvent complexes, s’agissant des degrés d’utilisation

et de facilitation des interfaces.

Ainsi, la Radio Voanio a proposé un stage pour l’automatisation de la gestion

de radiodiffusion, afin d’améliorer la qualité de gestion de l’ensemble de ses prestations

de services. En effet, connaitre les fonctionnements de la Radio diffusion est déjà une grande

opportunité. C’est une entreprise qui a des objectifs atteindre par ses actions. Elle a prouvée

son utilité malgré les problèmes qui existe au niveau de sa méthode de travail qui l’empêche

de bien travaillé. Elle contribue au développement social, culturel et économique du pays.

Mais certaines améliorations doivent être prises en compte, au niveau de la gestion pour que

l’entreprise soit beaucoup plus concurrentielle, d’où l’automatisation de pilotage administratif

de la station.

Le présent stage nous a permis de découvrir toutes les phases du processus d’analyse

des circuits de gestion et de conception à l’aide du langage UML. Le développement d’un tel

logiciel de gestion nous a permis d’enrichir nos connaissances en matière de programmation

(principe de réutilisation, robustesse et puis le respect des normes et qualité).

La réalisation d’un tel logiciel de pilotage administratif aide les responsables

de la Radio Voanio pour la prise de décisions nécessaires aux niveaux administratif,

stratégique et commercial. Mais le développement ne sera jamais fini totalement,

des interventions de dépannages ou des mis à jours sur certaines programmes seront possibles

afin que le logiciel serait à jours et répondrait également aux besoins de l’entreprise.

74

Bibliographie

Ouvrages généraux

DODO Sata, Rapport de stage de 2ème année de formation ingénieurs, « Automatisation de

gestion du centre de navigation internet de l’Université de Toamasina », 2003, 53 pages ;

GABAY Joseph, MERISE et UML, 5ème Edition, Dunod, Paris, 2004, 287 pages ;

KIRSTEIN Michael, Micro Application PC Poche, Visual Basic 6, 1ère Edition, Paris, 1999,

511 pages ;

LONCHAMP Jacques, Génie logiciel, Sixième partie « La modélisation objet UML », 2003,

17 pages ;

RM DI SCALA, les Bases de l’Informatiques et la Programmation, Paris, 2005, 914 pages ;

R. REIX, Informatique appliquée à la gestion, Éditions Foucher, Tome 2, 320 pages, 1990 ;

ZANDSTRA Matt, L’intro PHP4, 2000, 498 pages.

Textes réglementaires

Archives administratives de Radio Voanio, 2002 à 2009.

Notes de services de la Radio Voanio, 2003

Cours théoriques, dispensés à l’Université de Toamasina

ANDRIAMARO Henri, Cours Technique d’Analyse Organisationnelle, 3ème année Gestion,

option Informatique et Organisation, 2010 ;

BENONY Zacharie, Cours de Base de Données, 4ème année Gestion, 2010 ;

RAHAJANIAINA Andriamasinoro, Cours d’Algorithmique, 3ème année Gestion option

Informatique et Organisation, 2009 ;

75

RANDRIMANANTENA Modeste, Cours de Pratique Organisationnelle des Entreprises et de

Direction, 4ème année de Gestion option Informatique et Organisation, 2010 ;

VELO Jérôme, Cours de Technique de programmation, 3ème année Gestion option

Informatique et Organisation, 2009 ;

VELO Jérôme, Cours de Technique Générale d’Analyse, 4ème année Gestion option

Informatique et Organisation, 2010 ;

SITE WEB :

http://fr.html.net/tutorials/html/, novembre 2011

http://fr.html.net/tutorials/php/, novembre 2011

http://fr.wikipedia.org/wiki/Hypertext_Markup_Language, novembre 2011

http://fr.wikipedia.org/wiki/Unified_Modeling_Language, novembre 2011

http://laurent-audibert.developpez.com/Cours-UML/html/Cours-UML002.html, mars 2011

http://uml.developpez.com/, novembre 2011

http://uml.free.fr/, novembre 2011

http://uml.free.fr/index-cours.html, mars 2011

http://www.commentçamarche.com/, janvier 2012

http://www.commentcamarche.net/contents/uml/umlintro.php3, novembre 2011

http://www.developpez.com/, janvier 2012

http://www.madagascar-tribune.com/IMG/article_PDF/253-stations-de-radio-a-

Madagascar,4899.pdf, mars 2011

http://www.mysql.com/, janvier 2012

http://www.omda.mg/, mai 2011

http://www.omert.mg/, mai 2011

http://www.phpsources.org/scripts-MySQL-PHP.htm, janvier 2012

http://www.uml.org/, mars 2011

http://www.zone-webmasters.net/codes-sources/php/tous-codes-php.html, décembre 2011

76

ANNEXES

77

Annexes 1. Besoins d’une radiodiffusion (cas de Radio Voanio) Trois types de besoins apparaissent : Équipements, Humains et Services

Besoins d’équipement

Seuls ceux qui sont bien équipés, progressent vers la réussite ; et ceci dépend des

moyens disponibles. Pour les équipements, on peut les classer en deux groupes :

Équipements de base : minimum d’équipements pour la radiodiffusion utilisés de

façon permanente, dont les fondamentaux sont : la source d’énergie, l’émetteur,

l’antenne et les sources audio.

Équipements accessoires : des matériels de confort ou de nécessité relative,

équipements utilisés moyennement ou occasionnellement, tel que le casque d’écoute,

l’enregistreur dictaphone, les armoires, la lampe torche, …

Besoins humains

Pour un bon fonctionnement de l’entreprise et des équipements mis à disposition, deux

profils de personnels sont prévus :

Les postes obligatoires : Responsable de station, animateur, technicien, sécurité.

Les postes facultatifs : Agent de nettoyage, agent de services divers, etc.

Besoins de services

Les ressources de la radio se composent, essentiellement, de services publicitaires et

autres services commerciaux, nécessaires à la réalisation des objectifs et missions.

Ces services apportent à la radio des revenus commerciaux permettant de rémunérer ses

agents ; ainsi que pour subvenir à son bon fonctionnement et ses frais généraux.

La publicité et services publicitaires

La publicité est une forme de communication, dont le but est de fixer l'attention d’une

cible visée (consommateur, utilisateur, usager, etc.) pour l'inciter à adopter un comportement

souhaité : achat d'un produit, adoption et adhésion à un service, incitation à la consommation,

sensibilisation comportementale, etc.

Spot publicitaire

Le spot publicitaire ou « Spot Pub », est une voix enregistrée, souvent accompagnée d’un

fond musical. Généralement d’une durée maximale de 30 secondes, c’est un message rapide

78

mais portant l’attention de l’auditeur, sans l’ennuyer, grâce à la répétitivité de diffusion dudit

spot. Un spot se veut porteur d’information simple, claire et efficace en termes de

compréhension d’un large public. Les spots publicitaires se modernisent et incluent souvent

des sons musicaux adaptés à l’époque, tout en respectant l’attention de toutes les générations.

Annonce

Message personnel, demandé par un client, pour la diffusion, à travers la radio,

d’information, pour un grand nombre d’auditeurs et en même temps. L’annonce, comme son

nom l’indique, est souvent utilisée pour des évènements ou des faits de société : mariages,

naissances, décès, disparition d’une personne ou d’un animal, perte d’un objet, … ou encore

pour l’affichage de rendez-vous pour des réunions, coupures d’électricité, etc.

Dédicace

Presque similaire à une annonce, la dédicace est le fait de dédier une chanson à quelqu’un

de proche, souvent pour des évènements spécifiques (anniversaire, éloignement, pensée, etc.)

Émission « sponsoring »

C’est une séance de discussion ou de présentation sous forme publicitaire ou éducative qui

dure environ une heure maximum, en général. Les émissions sont souvent réalisées en

langage familier locale et traitent essentiellement des sujets de proximité et des

préoccupations de la population locale : pratiques agricoles, problèmes liés à la santé et au

bien-être, la sécurité alimentaire, etc. Souvent ce type d’émission est assorti d’un réel

dialogue entre les auditeurs et les animateurs, à travers le téléphone ou encore en présence

d’invités.

« Top horaire »

Il s’agit de l’annonce de l’heure, à travers l’horloge parlante, accompagnée d’un message

publicitaire « très court ». Généralement ce petit spot publicitaire ne dépasse pas

les 10 secondes. (Exemple : Radio Voanio et son équipe vous donne l’heure, il est dix heures).

Plateau

C’est une émission pendant laquelle, l’animateur de la radio, reçoit en directe un ou plusieurs

invités, pour traiter des sujets demandés par le client. L’émission sert essentiellement à

promouvoir un produit, un service, projets de sensibilisations, etc. L’objectif premier d’un

plateau est commercial, tendant à apporter l’éclairage nécessaire aux questions traitées, soit

sous forme de débat ou encore dans le cadre d’une série d’information explicative des sujets.

79

Matraquage

Lorsqu’un artiste « sort » une nouvelle chanson, et qu’il souhaite la faire connaître

« rapidement » par le grand public, le matraquage est le meilleur moyen pour répondre à ce

besoin. Il s’agit de diffusions répétitives et régulières (plusieurs fois par jour).

Autres services

Montage

Le montage est, l'action d'assembler, bout à bout, plusieurs plans ou séquences qui

formeront une émission ou publicité prêt à diffuser.

Organisation d’évènements à l’extérieur

La radio organise et anime des évènements à l’extérieur, dans des lieux publics

(restaurants, salle de réception, etc.) pour des anniversaires, mariages, défilés de mode, etc.

Organisation de jeux à l’antenne

Comme toutes les choses légères, le jeu radiophonique ne s’improvise pas. Il s’agit en

effet d’un concentré de divertissement utile qui rassemble et accommode tous les ingrédients

modernes de la radio pour en faire une mixture auditive séduisante : interactivité, de

proximité, récréation, suspens, humour, gratification. De plus, pour un objectif pédagogique,

le jeu peut être un excellent outil éducatif. Jouer peut rapporter gros à la radio en termes

d’audience, d’image, de notoriété et de messages à faire passer.

80

Annexes 2. Présentation générale de l’OMERT1

Compte tenu de l’importance du secteur des télécommunications pour le

développement social et économique du pays, l e Gouvernement avait procédé à une première

réforme en 1993 avec la séparation de la poste des télécommunications et l’établissement

d’une société de droit privé pour exploiter ce secteur.

Depuis cette première étape, l’environnement national et international dans le secteur

ont considérablement changé et continue encore d’évoluer. Les télécommunications, en tant

que support, se révèlent aujourd’hui comme un facteur clé de succès dans tous les secteurs de

l’économie. Le Gouvernement malgache a alors envisagé la seconde étape dans la réforme du

secteur, en vue d’accroître la participation du secteur privé dans le développement

harmonieux des services de télécommunication sur l’ensemble du territoire national et de

préciser les rôles distincts à jouer par l’État et le secteur privé.

Les autorités malgaches ont alors promulgué la loi n°96-034 du 27 janvier 1997,

portant réforme institutionnelle du secteur des télécommunications et qui prévoit

notamment la mise en place de l’Office Malagasy d’Études et de Régulation des

Télécommunications (OMERT) pour assurer les fonctions de régulation d’une manière

efficace, indépendante, transparente et impartiale. Il s’agit de garantir les règles qui

permettent à tous les opérateurs intervenant dans le secteur, d’assurer leurs intérêts.

L’OMERT devra également veiller qu’aucun opérateur n’empêche d’autres opérateurs

privés qui décident d’intervenir dans le secteur nouvellement ouvert à la concurrence, de

pouvoir développer leurs activités dans des conditions techniques et tarifaires satisfaisantes.

1http://www.omert.mg/home.htm

81

Annexes 3. Pouvoirs de l’OMERT1

Dans l’exercice de son mandat, l’OMERT a les pouvoirs nécessaires visant notamment à:

La comparution et l’interrogatoire des témoins ainsi que la production et l’examen des

pièces et l’inspection des biens.

La production et l’examen des documents relevant un différend entre titulaires des

licences, prestataires des services, et utilisateurs.

Établir les mises en demeures à l’encontre des titulaires des licences et de prestataires

des services en infraction ; si celles-ci restent sans effet, il applique les sanctions

prévues par la loi et la réglementation en vigueur.

Suspendre temporairement les licences dans les conditions fixées par la

réglementation.

Déposer les plaintes devant les tribunaux contre les titulaires des licences et les

prestataires des services refusant de régulariser leur situation ou les dénoncer aux

autorités répressives compétentes.

Assurer le recouvrement et l’utilisation des redevances de régulation, de gestion et de

contrôle des fréquences radioélectriques. Le montant des redevances de régulation est

fixé par décret, celui de la gestion et du contrôle des fréquences radioélectriques par

arrêté ministériel.

Faire publier au Journal Officiel de l’État et dans un rapport annuel public les textes

réglementaires qu’il propose, ainsi que les décisions particulières prises en application

de la présente loi.

Publier tout document qu’il estime nécessaire pour l’exécution de ses fonctions et

notamment en vue d’une consultation ou information publique.

1http://www.omert.mg/home.htm

82

Liste des figures

Figure 1. Outils et processus de transmissions radiophoniques ............................................... 15

Figure 2. Organigramme fonctionnel hiérarchique .................................................................. 17

Figure 3. Historique d’UML .................................................................................................... 31

Figure 4. Objets ........................................................................................................................ 34

Figure 5. Liens .......................................................................................................................... 35

Figure 6. Classe ........................................................................................................................ 36

Figure 7. Exemples d’associations ........................................................................................... 36

Figure 8. Hiérarchie de classes ................................................................................................. 39

Figure 9. Architecture d'UML .................................................................................................. 40

Figure 10. Cas d'utilisation ....................................................................................................... 44

Figure 11. Acteur ...................................................................................................................... 44

Figure 12. Interaction d'un système d’accès à la banque ......................................................... 45

Figure 13. Exemple: Diagramme de classe .............................................................................. 46

Figure 14. Diagramme de séquence ......................................................................................... 47

Figure 15. Composition et affinage de la commande ............................................................... 49

Figure 16. Package ................................................................................................................... 50

Figure 17. Diagramme de classe .............................................................................................. 51

Figure 18. Diagramme de contexte statique ............................................................................. 53

Figure 19. Diagramme de cas d'utilisation ............................................................................... 54

Figure 20. Acteur secondaire ................................................................................................... 55

Figure 21. Diagramme des activités ......................................................................................... 58

Figure 22. Diagramme de séquence à la réception de la commande ....................................... 59

Figure 23. Diagramme de séquence de préparation et la diffusion .......................................... 59

Figure 24. Diagramme de séquence de rapport de diffusion et de facturation ......................... 59

Figure 25. Diagramme de séquence d'encaissement de la facture ........................................... 60

Figure 26. Architecture à deux niveaux ................................................................................... 63

Figure 27. Architecture à trois niveaux .................................................................................... 64

Figure 28. Architecture générale de l'application..................................................................... 64

Figure 29. Erreur d'authentification : données obligatoires non saisies ................................... 66

Figure 30. Erreur d'authentification : mot de passe incorrect .................................................. 66

Figure 31. Liste des animateurs ................................................................................................ 67

83

Figure 32. Formulaire de saisie Fiche animateur ..................................................................... 68

Figure 33. Liste des clients ....................................................................................................... 68

Figure 34. Formulaire de saisie Fiche Client : Création et modification ................................. 69

Figure 35. Formulaire de la Commande ................................................................................... 69

Figure 36. Formulaire d'état fiche cabine ................................................................................. 70

Figure 37. Formulaire d'état facture ......................................................................................... 70

Liste des tableaux

Tableau n°I. Grille des horaires................................................................................................ 24

Tableau n°II. Présentation du partage de tâches entre les acteurs et le système ...................... 56

Tableau n°III. Récapitulatif des coûts ...................................................................................... 72

84

Table des matières

Sommaire ................................................................................................................................... 4

Remerciements ........................................................................................................................... 6

Liste des sigles, acronymes et abréviations ................................................................................ 7

Glossaire ..................................................................................................................................... 8

Introduction .............................................................................................................................. 12

1. Historique et présentation de Radio Voanio ........................................................................ 13

1.1. Présentation générale ..................................................................................................... 15

1.1.1. Généralités de la radio ............................................................................................ 15

1.1.2. Historique et statut juridique .................................................................................. 15

1.1.3. Les missions radiophoniques ................................................................................. 16

1.1.4. Structure de la radio ............................................................................................... 16

1.1.4.1. Organigramme ................................................................................................. 16

1.1.4.2. Les attributions des personnels ....................................................................... 17

1.1.4.3. Le règlement intérieur ..................................................................................... 20

1.1.5. Les obligations et règlementations ......................................................................... 21

1.1.5.1. Office Malagasy d'Études et de Régulation des Télécommunications ................ 21

1.1.5.2. Office Malgache de Droit d’Auteur ................................................................ 21

1.1.6. Les outils de gestion ............................................................................................... 21

1.1.6.1. Personnel ......................................................................................................... 21

1.1.6.2. Programme de Diffusion ................................................................................. 23

1.1.6.3. Gestion du temps ............................................................................................. 23

1.1.6.4. Gestion du matériel ......................................................................................... 24

1.1.6.5. Gestion commerciale ....................................................................................... 25

1.2. Analyse des circuits du travail et présentation du projet ............................................... 26

1.2.1. Bilan de l’existant ................................................................................................... 26

1.2.1.1. Au niveau des achats et ventes/services .......................................................... 26

1.2.1.2. Au niveau Programme de diffusion ................................................................ 26

1.2.1.3. Au niveau Personnel ........................................................................................ 26

1.2.1.4. Au niveau du Temps de travail ....................................................................... 26

1.2.1.5. Au niveau du Matériel ..................................................................................... 26

1.2.2. Présentation du système ......................................................................................... 27

85

1.2.2.1. Objectif du système ......................................................................................... 27

1.2.2.2. Intérêts du système .......................................................................................... 27

1.2.3. Cahier des charges de l’application ........................................................................ 27

1.2.3.1. Cahier des charges fonctionnelles ................................................................... 27

1.2.3.2. Cahier des charges non fonctionnelles ............................................................ 27

2. UML et l’analyse des circuits de diffusion .......................................................................... 28

2. 1. Survol du langage UML ............................................................................................... 30

2.1.2. Présentation d’UML ............................................................................................... 30

2.1.2.1. Les méthodes objets ........................................................................................ 31

2.1.2.3. Les méthodes d’analyse et de conception ....................................................... 32

2.1.2.4. Caractéristiques ............................................................................................... 32

2.1.3. Approche objet ....................................................................................................... 33

2.1.3.1. Modélisation d’un objet .................................................................................. 34

2.1.3.2. Les liens entre objets ....................................................................................... 35

2.1.3.3. Modélisation d’une classe ............................................................................... 35

2.1.3.4. Les autres concepts importants de l’approche objet ........................................ 38

2.1.4. Modélisation avec UML ......................................................................................... 39

2.1.4.1. Les démarches de l’élaboration de modèle ..................................................... 39

2.1.4.2. Élaboration des modèles .................................................................................. 42

2.1.4.3. Modélisation des vues statiques d’un système ................................................ 43

2.1.4.4. Modélisation des vues dynamiques d’un système ........................................... 46

2. 2. Analyse des circuits ...................................................................................................... 49

2.2.1. Principes ................................................................................................................. 49

2.2.1.1. Réification ....................................................................................................... 49

2.2.1.2. Autonomie et localité ...................................................................................... 49

2.2.1.3. Composition et affinage .................................................................................. 49

2.2.2. Aspect statistique .................................................................................................... 50

2.2.3. Aspect fonctionnel .................................................................................................. 52

2.2.4. Cas d’utilisation ...................................................................................................... 53

2.2.4.1. Identification des cas d’utilisation ................................................................... 53

2.2.4.2. Acteur secondaire ............................................................................................ 55

2.2.4.3. Description textuelle du cas d’utilisation ........................................................ 55

2.2.4.4. Description graphique du cas d’utilisation ...................................................... 57

3. Mise en œuvre ...................................................................................................................... 61

86

3.1. Conception .................................................................................................................... 63

3.1.1. Typologie des architectures .................................................................................... 63

3.1.1.1. Scénario à deux niveaux .................................................................................. 63

3.1.1.2. Scénario à trois niveaux .................................................................................. 63

3.1.2. Architecture générale de l’application ................................................................... 64

3.2. Réalisation ..................................................................................................................... 65

3.2.1 Environnement de développement .......................................................................... 65

3.2.2. Application réalisée ................................................................................................ 65

3.2.2.1 Installation et Configuration ............................................................................. 65

3.2.2.2 Les fonctionnalités du système ........................................................................ 66

3.2.3. Impacts du nouveau système .................................................................................. 71

3.2.3.1. Impacts internes ............................................................................................... 71

3.2.3.2. Impacts externes .............................................................................................. 71

3.2.4. Évaluation des coûts ............................................................................................... 71

3.2.4.1. Coût de réalisation ........................................................................................... 71

3.2.4.2. Coût d’installation ........................................................................................... 71

Conclusion ................................................................................................................................ 73

Bibliographie ............................................................................................................................ 74

ANNEXES ............................................................................................................................... 76

Annexes 1. Besoins d’une radiodiffusion (cas de Radio Voanio) ........................................ 77

Annexes 2. Présentation générale de l’OMERT .................................................................. 80

Annexes 3. Pouvoirs de l’OMERT ...................................................................................... 81

Liste des figures ....................................................................................................................... 82

Liste des tableaux ..................................................................................................................... 83