Exemple de rapport de stage secrétariat bureautique
Exemple de rapport de stage secrétariat bureautique PDF
...
Introduction
Depuis Graham BELL, la téléphonie fait toujours des merveilles en passant d’un niveau à un autre plus sophistiqué. De nos jours la téléphonie présente de grands horizons. Elle présente pour les entreprises de prestation de services un outil primordial pour réussir dans le marché. Avoir la confiance des clients est la clé de cette réussite; en effet, le client apprécie que l’entreprise accorde un grand intérêt à ses affaires et cela surgit des contacts téléphoniques, l’outil indispensable de communication. Ainsi, ces entreprises attachent de l’intérêt à ce facteur en essayant de leur mieux d’adopter toujours les dernières solutions présentes pour assurer cette confiance et pour montrer aux clients que l’entreprise connaît les détails de leurs actions et leurs projets en cours. Par ailleurs, l’informatique envahit tous les domaines, répondant aux différents besoins de l’entreprise, partant de la simple gestion des réseaux locaux vers le e-commerce.
C’est pour cette raison qu’une fusion entre téléphonie et informatique s’avère indispensable. De grands efforts sont fournis dans cette voix et les applications de CTI (Couplage Téléphonie Informatique) sont bien nombreuses. Mais TAPI reste l’outil le plus utilisé; en fait c’est une interface qui assure la communication avec les outils usuels de téléphonie standard, notamment les PBX, en fournissant à l’ordinateur toutes les informations reçues par le PBX pour des traitements opportuns. Bref, le couplage téléphonie informatique présente une bonne alternative pour les entreprises qui veulent se mettre à jour et améliorer leur système téléphonique.
C’est dans cette perspective que POWERNET(*) a voulu adopter la solution TAPI pour développer une application de gestion de contacts. Le présent rapport résume toutes les étapes et les tâches effectuées tout au long de la période de travail sur ce projet avec éventuellement toutes la documentation utile pour une bonne compréhension de cette nouvelle technologie.
- Travail demandé :
Le projet consiste en la réalisation d’une application de gestion des appels entrants. Il s’agit d’utiliser l’interface TAPI pour récupérer les informations échangées dans le PBX et les stocker dans une base de données afin de s’en servir dans la gestion des contacts.
L’application demandée consiste en :
- L’obtention de l’historique des appels entrants et sortants.
- La réalisation des fiches personnalisées pour les contacts de l’entreprise ;
la fiche contiendra entre autres les dernières opérations avec le client.
En effet, elle doit s’afficher dès que l’application détecte un appel de ce contact. Cette application doit assurer tout de même l’insertion, la suppression et la mise à jour des données stockées dans la base de données des contacts. Puisque notre application se base sur TAPI, la première tâche demandée était une maîtrise de cet outil avant de passer au développement des traitements souhaités. Ainsi nous avons opté pour le plan d’action illustré par la figure ci-après :
…
- Outils de développement
1) TAPI :
L’interface TAPI (1) (Telephony Application Programming Interface) se décompose en trois couches : (voir figure 2)
La couche applicative : c’est l’interface avec l’utilisateur, lui permettant d’exploiter les services fournis par l’interface TAPI.
Service TAPI : offre des fonctions de téléphonie pour l’application.
Un fournisseur de services TAPI : ce sont des bibliothèques de liaison dynamique (DLL) qui traduisent les commandes pour un périphérique ou un protocole de téléphonie.
Figure 2 : les couches logiciels de l’interface TAPI
Elle intègre les télécommunications à l'ordinateur. TAPI prend en charge à la fois la téléphonie traditionnelle RTC et la téléphonie IP pour offrir des possibilités de transmission vocale,
vidéo et de données. Outre l'émission et la réception des appels, des programmes peuvent utiliser l'interface TAPI pour fournir des fonctionnalités supplémentaires de téléphonie telles que l'ID de l'appelant, le routage d'appel, la messagerie vocale et la vidéoconférence.
En effet, l'interface TAPI gère tous les signaux qui transitent entre un ordinateur et un réseau téléphonique, y compris les fonctions de base d'un appel telles que la numérotation, la réponse et le raccrochage. Elle intègre également des fonctions supplémentaires, telles que la mise en attente, le transfert, la conférence et la mise en garde d'appel. En plus, elle permet aux utilisateurs d'effectuer des appels sur des réseaux IP.
Grâce à son architecture en couches l'interface TAPI commune permet aux différents programmes de communication de fonctionner conjointement et de se partager les différents périphériques de communication. (Voir figure 3)
…
2) La lecture à partir du port COM (voir figure 4)
En général, les périphériques de téléphonie sont connectés au port COM de l’ordinateur via un câble RS232. Par conséquent, la lecture à partir du port donne accès à toutes les données échangées entre l’ordinateur et le périphérique de téléphonie. Cette solution de communication directe sans couches intermédiaires évite toute perte d’information pouvant agir dans ses couches. AT command est le langage utilisé par l’ordinateur pour communiquer avec le modem. L’envoi de ces commandes à travers le port COM permet une maîtrise de toutes les fonctionnalités du modem et une grande marge de manœuvre. D’ailleurs le fournisseur de service TAPI des modems est développé en AT Command.
Cependant, l’utilisation du port COM nous prive de tous les avantages que présente l’interface TAPI, notamment l’indépendance du matériel, et complique le développement. Aussi, préconisions nous le recours à l’interface TAPI et nous n’étions amenés à l’emploi du port COM que lorsque TAPI ne fournit pas les résultats attendus.
Figure 4 : la connexion via le port Com
3) Visuel Basic 6:
L’outil que nous avons employé pour développer le module demandé de récupération de l’ID de l’appelant était VB6. Contrairement au .NET, le VB6 offre un outil approprié pour la gestion de la communication par les ports de l’ordinateur sans passer par l’API Windows. Cet outil est le contrôle MSComm. En effet, le contrôle du port Com à travers vb.net présente beaucoup de lacunes puisque les modules conçus pour cet objectif (voir annexe 2) sont instables et sont en cours de développement. Par conséquent, nous avons opté pour l’outil le plus stable et le plus simple à la fois.
III.Le travail effectué :
1) Analyse de l’existant :
Architecture du réseau téléphonique :
PowerNet dispose de deux ligne téléphonies, le 98 et 99. La ligne 99 est réservée au faxe et à la connexion ADSL. La deuxième ligne, 98 est connectée derrière le standard téléphonique de l’entreprise.
- Le PBX :
Figure 5 : le PBX Panasonic KX-TA308
- L’utilisation de TAPI :
Le PBX utilisé ici est un PBX analogique de Panasonic KX-TA308. Le projet de départ était de le connecter à l’ordinateur afin de récupérer les informations sur les appels via l’interface TAPI. Après des premiers tests non fructueux utilisant des applications de téléphonie TAPI il s’est avéré que son fournisseur de service TAPI (TSP) n’est pas fourni par windows. Ainsi, nous nous sommes retournés vers le site du constructeur (2) pour davantage de précision sur son matériel. La fiche de ce KX-TA308(3) ne fait pas allusion au support de telles fonctionnalités de téléphonie, mais une comparaison avec d’autres PBX du même constructeur ainsi qu’un examen de la documentation du notre, nous ont prouvé que ce modèle ne supportait pas l’interface TAPI. Une alternative pour surmonter cet handicap était de développer notre propre TSP pour ce standard. Or, la complexité d’une telle tâche, et la nécessité d’avoir plus d’expérience pour pouvoir l’effectuer étaient décourageantes.
La lecture à partir du port COM :
La non compatibilité du PBX disponible avec une interface aussi universelle que TAPI prive ainsi l’application finale de l’indépendance du matériel employé souhaitée au départ du projet. Néanmoins, le but étant de gérer les appels, il suffit de faire communiquer le PBX et l’ordinateur. Le seul moyen pour assurer cet échange est de les connecter via un câble RS232, puis lire des données reçues sur le port COM de l’ordinateur par une applications appropriée(4) afin d’en faire usage par l’application de téléphonie.
Le test n’a révélé aucun échange d’informations lors de la réception ou l’envoi d’un appel par le PBX. En fait, l’obtention des informations sur l’activité du PBX ne se fait pas en mode asynchrone : il faut arrêter toutes les communications et passer en mode programmation pour pouvoir le faire, ce qui est à l’encontre de notre application.
- Le caller ID :
Ce modèle du PBX ne fournit pas le numéro de l’appelant. Ainsi toute alternative consistant à connecter un périphérique, notamment un modem, qui transmet les données à l’ordinateur, derrière le PBX serait handicapée par l’absence de cette information cruciale. Afin de surpasser cet obstacle il faudra y installer le « Caller ID card » (voir figure 6). Dans ce cas, il faudrait s’assurer que le périphérique branché à ce PBX transmet bien le numéro de l’appelant à l’ordinateur. Ce point sera discuté en détail dans le cas du modem.
- Le modem
- Les modems utilisés :
Afin d’employer un modem pour la téléphonie il est indispensable qu’il soit un modem vocale ce qui pourrait être vérifié à l’aide des AT Command. Durant le stage, deux modems ont servi pour effectuer les tests :
1 un modem externe « Intel V92 External Modem » de Orange (5)
2 un modem interne « Intel V92 HaM Data Fax Voice »
Nous n’avons pas constaté une grande différence dans le comportement de ces deux modems durant les tests.
- La notification des appels
La ligne utilisée pour effectuer les tests était le 99. Le fournisseur de service TAPI de tous les modems « unimodem » étant fourni avec Windows (6), les applications TAPI fonctionnent correctement avec le modem au niveau de l'envoi et de la réception des appels. Néanmoins, ces dernières n'arrivaient pas à afficher le numéro de l'appelant dans le cas d'un appel entrant. L'étape de la communication avec l'ordinateur et de la notification de l'appel étant franchise, nous nous sommes concentrés par la suite sur la récupération du numéro de l'appelant (le caller ID)
- Le caller ID
Dans cette étape nous avons opté pour l'utilisation des AT Command qui donnent accès à une communication directe avec le modem, ainsi, nous évitons toute perte pouvant agir dans une couche intermédiaire (TAPI).
Suite à une longue recherche dans des sites spécialisés des modems et du caller ID (7), nous avons réussi à recenser toutes les éventuelles causes de l’absence du numéro de l’appelant :
1- Cette information n’est pas fournie par l’opérateur.
2- La fonctionnalité de fournir le numéro de l’appelant n’est pas activée.
3- Le modem n’accepte pas cette fonctionnalité.
4- Il l’accepte mais il utilise un standard différent de Maroc Telecom.
La première hypothèse est facile à rejeter vu que Maroc Telecom fournit toutes les données sur l’appel dont l’ID de l‘appelant. La deuxième est la plus probable vu que la transmission de cette information à l’ordinateur est désactivée au départ. L’activation de cette fonctionnalité consistait à envoyer au modem une commande appropriée (8). Cependant, après cette manipulation, l’écoute du port COM n’a révélé aucun transfert de données hormis la notification de l‘appel (la chaîne de caractères RING). Quant à la troisième hypothèse, nous ne sommes pas en mesure de trancher vu que la fiche descriptive du modem, fournie par le constructeur, n’était pas explicite sur ce point (9). En plus, le Maroc n’est pas présent dans la liste des pays à l’onglet « paramètres avancées » des propriétés des deux modems utilisés. Aussi, se renforce la probabilité que le format sous laquelle les informations sont délivrées au modem est différent du format attendu. Le modem ignore alors ces données et ne les transmet pas à l’ordinateur.
2) Le livrable :
Afin de surpasser l’handicap du matériel qui avait marqué le projet nous avons développé un module qui fait abstraction du matériel. En effet, quelque soit le périphérique utilisé, l’interface de communication avec l’ordinateur serait le port com. Notre module consistait alors en deux fonctions. L’une pour lire les données reçues sur le port COM et la deuxième pour en extraire le numéro de l’appelant.
+ La fonction recupererDonnees
Cette fonction lit les informations présentes dans le buffer d’entrée du port passé en paramètre puis les retourne sous forme de « String ». Il faudrait noter qu’elle n’ouvre pas le port, l’application doit alors le choisir et l’ouvrir. À la réception d’un appel elle appelle cette fonction et traite les informations retournées.
+ La fonction Extraire CID Cette fonction prend en paramètre une chaîne de caractère qui serait la valeur de retour de recupererDonnees. Elle en extrait le caller ID qui est, en général, la chaîne de caractère succédant « NMBR = », puis elle le retourne à l’application sous forme de « String ». Au cas où le numéro de l’appelant n’est pas précédé par la chaîne signalée, il suffit de la remplacer dans le code.