rapport de stage - kdp ab

54
Rapport de stage Développement et déploiement d’une GRC Cyril DEFAUT Maître de stage : Rodolphe ALBEROLA Tuteur de stage : Isabelle JACQUES Stage au sein d’Avenir Bureautique (Besançon) du 5 Mars au 8 Juin 2012 LICENCE PROFESSIONNELLE Systèmes Informatiques et Logiciels spécialité Conception et Développement Orientés Objet d'Applications Multitiers Année universitaire 20112012

Upload: dinhdien

Post on 05-Jan-2017

236 views

Category:

Documents


0 download

TRANSCRIPT

                                                                                         

Rapport  de  stage    

Développement  et  déploiement  d’une  GRC  

     

Cyril  DEFAUT  Maître  de  stage  :  Rodolphe  ALBEROLA  -­‐  Tuteur  de  stage  :  Isabelle  JACQUES  

   

 Stage  au  sein  d’Avenir  Bureautique  (Besançon)  

du  5  Mars  au  8  Juin  2012    

         LICENCE  PROFESSIONNELLE  Systèmes  Informatiques  et  Logiciels  spécialité  Conception  et  Développement  Orientés  Objet  d'Applications  Multi-­‐tiers    Année  universitaire  2011-­‐2012  

Rapport de stage

Programmation d'un logiciel chargé de piloterun banc d'encodage de cartes magnétiques

et de gérer les mappings de cartes

Romain DÉOUX

Maître de stage : Christian PERROTTutrice enseignante : Isabelle JACQUES

Licence professionnelle C.D.O.A.M.Conception et Développement Orientés Objets d’Applications Multi-tiers

Université de Franche-Comté – L.I.F.C.

Année universitaire 2009 / 2010

1/46

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  1  -­‐  

 

Sommaire      

Sommaire   1  

Remerciements   3  

Introduction   4  

1-­‐Avenir  Bureautique   5  1.1-­‐Présentation  de  l’entreprise   5  1.2-­‐Historique   5  1.3-­‐Quelques  chiffres   6  1.4-­‐Sigec   6  1.5-­‐Environnement  de  travail   7  

2-­‐Sage  CRM  Vente  Partner   8  2.1-­‐GRC  :  définition   8  2.2-­‐Vente  Partner  :  son  histoire   8  2.3-­‐Son  arrivée  chez  Avenir  Bureautique   9  

3-­‐L’existant   11  3.1-­‐Définitions   11  

3.1.1-­‐Vue   11  3.1.2-­‐Famille   11  3.1.3-­‐Fiche   11  

3.2-­‐Base  de  données   12  3.3-­‐Diagramme  de  classes   13  

4-­‐Le  développement   15  4.1-­‐Cahier  des  charges   15  4.2-­‐Premiers  jours  de  stage   15  4.3-­‐Consolidations   16  4.4-­‐Groupes  d’accès  et  utilisateurs   17  4.5-­‐Vues   18  

4.5.1-­‐Objet  saisie   19  4.5.2-­‐Bouton  action   20  4.5.3-­‐Objet  externe   20  

4.6-­‐Agenda   20  4.7-­‐Traitements   22  

4.7.1-­‐Listes  de  travail   23  4.7.2-­‐Editions   24  4.7.3-­‐Dossiers   25  4.7.4-­‐Exports   26  4.7.5-­‐Graphiques   26  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  2  -­‐  

4.7.6-­‐Etiquettes   27  4.8-­‐Relooking   28  4.9-­‐Tâches  annexes   28  

Conclusion   29  

Glossaire   30  

Webographie   31  

Annexes   32  Annexe  A  :  L’ancienne  mouture  de  la  GRC   32  Annexe  B  :  Le  cahier  des  charges   39  Annexe  C  :  La  nouvelle  mouture  de  la  GRC   44  Annexe  D  :  Exemple  d’éditions   50  

Résumé   53  

Abstract   53    

   

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  3  -­‐  

 

Remerciements    

Je   souhaite   tout   d’abord   exprimer   ma   reconnaissance   envers   Mr   Rodolphe  ALBEROLA   pour   m’avoir   accueilli   au   sein   d’Avenir   Bureautique,   pour   m’avoir   fait  confiance   durant   le   déroulement   du   stage   et   pour   avoir   toujours   su   répondre   à   mes  diverses  questions.  

 Mes  remerciements  vont  aussi  à  :  -­‐   Mr   Frédéric   CHARANSOL,   directeur   commercial   de   Sigec   et   administrateur  

d’Avenir  Bureautique  et  de  Sigec,  pour  sa  participation  à  l’étude  de  la  GRC  et  pour  avoir  servi  de  lien  entre  les  2  sociétés  ;  

-­‐  Mr  Yannick  DEROUBAIX,  technicien  de  Sigec,  pour  le  partage  de  son  expérience  sur  Vente  Partner  et  son  aide  pour  le  déploiement  ;  

-­‐  Mr   Bertrand   ELINEAU,   technicien   de   Technomade,   pour   son   aide   précieuse   lors  des  problèmes  survenus  durant  le  développement  de  la  GRC  ;  

-­‐  aux  équipes  commerciales  qui  ont  toujours  été  là  pour  satisfaire  à  mes  différentes  demandes,  soumettre  leurs  doléances  et  remonter  les  problèmes  rencontrés  sur  la  GRC  modifiée.  

 Je  tiens  aussi  à  remercier  l’ensemble  des  salariés  de  l’entreprise  pour  leur  amabilité  

et  l’accueil  agréable  qu’ils  m’ont  réservé  et  qui  m’ont  permis  de  m’adapter  rapidement  à  ce  nouveau  cadre  de  travail.  

 Enfin,   j’exprime   ma   gratitude   envers   Mr   Jacques   THIBAULT,   directeur   général  

d’Avenir  Bureautique  et  de  Sigec,  pour  m’avoir  offert  l’opportunité  d’intégrer  à  l’issue  du  stage  la  société  Axess  Vision.        

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  4  -­‐  

 

Introduction    Dans  le  cadre  d’un  départ  de  l’Armée  de  l’Air,  après  y  avoir  passé  16  années  en  tant  

qu’informaticien,  et  afin  de  me  préparer  à  un  retour  à  la  vie  civile,  j’ai  décidé  d’effectuer  une   reconversion   en   reprenant   mes   études.   Mon   choix   s’est   porté   sur   la   licence  professionnelle   «  Systèmes   Informatiques   et   Logiciels   spécialité   Conception   et  Développement  Orientés  Objet  d'Applications  Multi-­‐tiers  »  

 Ce  cursus,  dispensé  à  l’Université  de  Franche-­‐Comté  de  Besançon  durant  une  année  

universitaire,  est  validé  par   l’intermédiaire  d’un  stage  en  entreprise  d’une  durée  de  14  semaines.  

 Ce   stage   a   été   réalisé   au   sein   d’Avenir   Bureautique   à   Besançon.   Cette   entreprise,  

spécialisée  dans  les  systèmes  de  reproduction  et  de  communication,  m’a  accueilli  dans  le  cadre   d’un   projet   de   développement   d’une   nouvelle   GRC   en   remplacement   d’une  ancienne   devenue   obsolète   et   inadéquate.   A   l’heure   où   la   concurrence   est   rude   pour  obtenir  des   contrats,   les   commerciaux   se  devaient  d’avoir  un  outil   performant   afin  de  suivre   au   plus   près   les   engagements   pris   auprès   de   leurs   clients   et   de   répondre  rapidement  et  précisément  à  leurs  besoins.  

 Ce   rapport   expose   le   déroulement   de   mon   stage.   Tout   d’abord,   je   présente  

l’entreprise  et  la  GRC  existante  qui  sert  de  base  à  la  nouvelle  version.  Ensuite,  je  décris  le  cahier  des  charges  et  je  détaille  les  différentes  étapes  du  développement  accompli  ainsi  que   les   problèmes   rencontrés.   Enfin,   j’effectue   un   bilan,   tant   sur   le   plan   des  connaissances  utilisées  que  sur  celles  qui  m’ont  été  apportées  par  l’entreprise.  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  5  -­‐  

 

1-­‐Avenir  Bureautique    

1.1-­‐Présentation  de  l’entreprise    Avenir  Bureautique  est   spécialisé  dans   la  diffusion  et   la  maintenance  de  matériels  

bureautiques  et  solutions  réseaux.  Une  large  gamme  de  fax,  imprimantes,  multifonctions  et  photocopieurs  est  proposée  

en  achat  ou  en  location.  2  marques  sont  proposées  :  -­‐  Konica  Minolta   (Avenir  Bureautique  est  un  distributeur  national  agréé)  pour  des  

imprimantes  et  multifonctions  ;  -­‐  Oki  pour  des  imprimantes.    Les  appareils  en  fin  ou  en  cours  de  location  (provenant  de  chez  Avenir  Bureautique  

ou  d’un  de  ses  concurrents)  sont  repris  régulièrement  afin  de  permettre  aux  clients  (ou  futurs   clients)  d’évoluer   selon   leurs  nécessités   sur  des   équipements  plus   récents,   plus  performants   et   donc   plus   appropriés.   La   formation   du   personnel   sur   les   nouvelles  machines   est   effectuée   par   les   commerciaux   tandis   que   les   techniciens   s’occupent   de  l’installation  et  de  la  connexion  des  matériels  sur  le  site  de  déploiement  des  entreprises  bénéficiaires.   En   outre,   la   gestion   des   consommables   est   intégrée   à   tout   contrat   de  maintenance  :  les  sociétés  clientes  doivent  seulement  faire  part  de  leurs  besoins  auprès  de  la  centrale  d’accueil  d’Avenir  Bureautique  et  un  technicien  se  déplacera  rapidement  pour  délivrer  la  commande.  

 

1.2-­‐Historique    

1979  :  création  d’Avenir  Bureautique  à  Granvelle  (70)  par  Mr  Raymond  CLADE  1981  :  implantation  de  la  société  à  Besançon  (25)    

 Fig.  1  :  Siège  social  à  Besançon  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  6  -­‐  

 1995  :   l’entreprise   est   rachetée   par   Mrs   Jacques   THIBAULT,   Frédéric   CHARANSOL   et  Rodolphe  ALBEROLA  1996  :  création  d’une  agence  à  Montbéliard  (25)  1997  :  création  d’une  agence  à  Dijon  (21)  

 Les  différentes  agences  couvrent  toute  la  Franche-­‐Comté  ainsi  que  la  Côte  d’Or.    

 Fig.  2  :  Emplacement  des  agences  

 

1.3-­‐Quelques  chiffres    Le  personnel  de  la  société  (agences  comprises)  est  constitué  de  35  collaborateurs  :  -­‐  12  commerciaux  (3+  1  chef  de  vente  par  site)  ayant  chacun  son  propre  secteur  ;  -­‐  17  personnes  affectées  au  service  de  maintenance  et  réparties  géographiquement  

sur  l’ensemble  des  sites.  6000   interventions   techniques   sont   effectuées   par   an   pour   un   parc   de   2700  

machines  sous  contrat  d’entretien  localisées  en  Franche-­‐Comté  et  en  Côte  d’Or.  500  autres  machines  sont  placées  par  an  dans  le  même  périmètre.  Le  chiffre  d’affaire  d’Avenir  Bureautique,  toujours  en  constante  progression,  a  été  de  

4,5   millions   d’euros   en   2009   puis   de   5,5   millions   d’euros   en   2010   pour   finalement  tourner  autour  des  6  millions  d’euros  pour  l’année  2011.  

 

1.4-­‐Sigec    Puisque  j’ai  introduit  Avenir  Bureautique,  je  me  dois  aussi  de  présenter  brièvement  

la  société  Sigec.  Pourquoi  cette  démarche  ?  La  GRC  développée  au  sein  d’Avenir  Bureautique  est  autant  utile  pour  cette  dernière  

que  pour  Sigec  dans  la  mesure  où  ces  2  entités  font  partie  du  même  groupe  et  emploient  l’ancienne  version  pour  les  mêmes  raisons  commerciales.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  7  -­‐  

 Sigec   est   la   contraction   de   Service   Informatique   de   GEstion   et   Conseil.   Cette  

entreprise  est  implantée  sur  Besançon  depuis  plusieurs  décennies.  A  l’instar  d’Avenir  Bureautique,  elle  offre  des  solutions  d’impressions  par  le  biais  de  

plusieurs  marques  :  -­‐  Ricoh  pour  les  multifonctions  et  photocopieurs  ;  -­‐  Riso  pour  les  dupli  copieurs  ;  -­‐  Oki  pour  les  imprimantes.  

[NOTA  :   un   dupli   copieur   est   un   copieur   employé   pour   des   besoins   d’impression   de  documents  en  grand  nombre  comme  des  tracts  par  exemple]    

Toutefois,   ce   n’est   pas   là   son   seul   domaine   de   vente.   Elle   propose   également   ses  compétences  en  :  

-­‐  matériels  informatiques  et  logiciels  de  gestion  ;  -­‐  biométrie   (reconnaissance  et   identification  de  personnes,   contrôle  et  gestion  des  

accès,  gestion  du  temps  de  travail  et  des  horaires,  etc.)  ;  -­‐  mobilier  de  bureau.  

 En   plus   de   l’agence   (et   siège   social)   de   Besançon,   Sigec   possède   plusieurs  

succursales  :  -­‐  à  Audincourt  (25)  ;  -­‐  à  Sennecey-­‐les-­‐Dijon  (21)  ;  -­‐  à  Chaumont  (52)  ;  -­‐  et  récemment  à  Puget-­‐sur-­‐Argens  (83).  Les  différentes  agences  couvrent  toute  la  Franche-­‐Comté  ainsi  que  la  Côte  d’Or  et  la  

Haute-­‐Marne.    

1.5-­‐Environnement  de  travail    Avenir   Bureautique   ne   possédant   pas   de   service   informatique,   je   dépendais  

directement  du  directeur  commercial  et  responsable  du  stage,  Mr  Rodolphe  ALBEROLA.  Ensemble,  nous  avons  échangé  des  avis  et  visualisé   les  étapes  de   l’évolution  de   la  GRC  lors  de  réunions  quasi  quotidiennes.  

J’ai   eu   aussi   l’opportunité   d’aller   plusieurs   fois   sur   les   sites   de   Dijon   et   de  Montbéliard  afin  d’en  connaître  le  personnel  et  de  pouvoir  aussi  partager  des  idées  sur  le  futur  logiciel.  

J’étais  installé  dans  le  bureau  des  commerciaux  ce  qui  me  permettait  d’avoir  des  avis  et   des   retours   d’informations   sur   les   différentes   phases   de   développement   et   de  déploiement.    

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  8  -­‐  

 

2-­‐Sage  CRM  Vente  Partner    

2.1-­‐GRC  :  définition    GRC  signifie  Gestion  de  la  Relation  Clients  (elle  est  connue  aussi  sous  le  nom  de  CRM  

pour  Customer  Relationship  Management).  [NOTA  :  pendant  la  durée  du  stage,  moi-­‐même  et  mes  interlocuteurs  avons  toujours  

employé  le  terme  CRM  et  non  pas  GRC]    La  GRC  est  une  application  informatique  de  type  progiciel  permettant  de  renseigner,  

traiter  et  analyser  des  informations  relatives  aux  clients  et  aux  prospects  dans  le  but  de  renforcer  la  communication  entre  eux  et  l’entreprise  détentrice  de  la  GRC  et  d’aider  à  les  fidéliser  en  leur  offrant  les  meilleurs  services  possibles.  

Ces  objectifs  sont  réalisés  en  automatisant  les  différentes  composantes  de  la  relation  client  telles  que  :  

-­‐   l’avant-­‐vente   (en   analysant   et   en   anticipant   les   besoins   futurs   des   clients   et   de  démarcher  les  prospects)  ;  

-­‐   la  vente  (en  apportant  aux  commerciaux  des  outils  afin  de  les  assister  dans  leurs  démarches   de   prospection   comme   la   gestion   des   contacts,   des   rendez-­‐vous   ou   des  relances)  ;  

-­‐   la   gestion   du   service   clientèle   (en   faisant   apparaître   l’historique   d’un   client   à  chaque  prise  de  contact  de  celui-­‐ci  avec  l’entreprise  propriétaire  de  la  GRC)  ;  

-­‐  l’après-­‐vente  (en  fournissant  une  assistance  au  client  via  un  centre  d’appel  ou  des  techniciens  grâce  au  partage  des  données  le  concernant).  

 En   conclusion,   un   projet   de   GRC   consiste   à   permettre   à   chaque   intervenant   de  

différents  secteurs  d’une  entreprise  d’accéder  à  un  système  d’informations  pour  être  en  mesure  d’améliorer  la  connaissance  du  client  et  de  lui  fournir  des  produits  ou  services  répondant  au  mieux  à  ses  attentes.  

 

2.2-­‐Vente  Partner  :  son  histoire    Vente   Partner   est   un   logiciel   conçu   afin   d’intégrer   en   standard   l’ensemble   des  

fonctions  requises  par  la  GRC.  Il  a  été  créé  au  début  des  années  1990  par  KDP  Informatique,  un  éditeur  français  de  

solutions  de  GRC.    

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  9  -­‐  

 [NOTA  :   pendant   la   durée   du   stage,   pratiquement   tous   mes   interlocuteurs  

nommaient  le  logiciel  KDP  plutôt  que  Vente  Partner]  Celui-­‐ci  a  été  très  bien  accueilli  par   les  sociétés  ou  groupes  nationaux  et  étrangers  

installés  en  France.  Ainsi,  KDP  Informatique  a  eu  des  clients  prestigieux  tels  que  :  -­‐  Alstom  ;  -­‐  Colas  ;  -­‐  Facom  ;  -­‐  Groupe  Aoste  ;  -­‐  La  Redoute  ;  -­‐  Outils  Wolf  ;  -­‐  Parc  du  Futuroscope  ;  -­‐  Smoby  ;  -­‐  Stoeffler  ;  -­‐  TPS  ;  -­‐  Tetra  Pak  Service  ;  -­‐  Total  France.    En   septembre   2007,   cet   éditeur   est   racheté   puis   absorbé   par   Sage   Group,   une  

entreprise  britannique  éditrice  de  logiciels  et  spécialisée  aussi  dans  les  logiciels  de  GRC,  dans  le  cadre  d’une  politique  forte  d’acquisition  en  France.  

 Après  cette  prise  de  contrôle,  Vente  Partner  est  rebaptisé  Sage  CRM  Vente  Partner.  

Le   logiciel   continue   son   évolution   au   fil   du   temps   par   le   biais   de   différentes   versions  grâce  à  l’expérience  et  à  l’innovation  de  Sage  Group,  actuellement  troisième  fournisseur  mondial  de  progiciels  de  gestion  intégrés.  

La  version  12.0,  dernière  et  ultime  version,  est  sortie  début  2012.    

2.3-­‐Son  arrivée  chez  Avenir  Bureautique    Avenir  Bureautique  et  Sigec  décidèrent  d’acheter  ensemble  une  solution  GRC  pour  

leurs  activités  commerciales  communes  de  revendeur  de  solutions  d’impressions.  Leur  choix  se  porta  sur  Vente  Partner  car,  outre  ses  fonctions  de  gestion,  il  est  possible  d’en  modifier  facilement  l’environnement  afin  de  réaliser  une  application  sur  mesure.  

 Le   développement   a   été   effectué   par   Mr   Jean   NORBET,   technicien   de   KDP  

Informatique,  selon  un  cahier  des  charges  fourni  par  les  2  entreprises.  En  1998,  le  logiciel  est  déployé  au  sein  de  ces  2  entreprises  :  il  est  basé  sur  la  version  

4.0.Il   s’agit   d’une   version   client/serveur   développée   en   langage   orienté   objet   C++,  associé   à   un   SGBD   relationnel  ;   les   accès   et   récupération   des   données   se   font   par   des  requêtes  soit  de  type  QBE  soit  de  type  SQL.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  10  -­‐  

 Puis,  en  2002,  la  version  5.0  est  installée  pour  accompagner  le  passage  à  la  monnaie  

unique.  Aucun  changement  de  version  ou  rectification  du  contenu  n’a  été  exécuté  depuis  sur  

Vente  Partner.  En   2011,   cet   outil   étant   devenu   vieillissant   et   inadéquat   pour   les   besoins   des   2  

sociétés,  il  fut  décidé  de  passer  à  la  version  la  plus  récente  du  logiciel  et  d’améliorer  son  interface.   KDP   Informatique   n’existant   plus,   c’est   Technomade,   entreprise   bordelaise  revendeuse   agréée   Sage,   qui   installa   la   version   12.0   à   la  mi-­‐février   2012   chez   Avenir  Bureautique  et  Sigec.  

 Concernant  la  partie  développement,  le  travail  fut  fourni  à  un  programmeur  :  c’est  là  

que  j’interviens  et  que  commence  mon  stage.    

   

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  11  -­‐  

 

3-­‐L’existant    Le   but   de   mon   stage   n’étant   pas   de   concevoir   une   nouvelle   application   mais  

d’améliorer   l’interface  d’une  GRC  en   repartant  de   ce  qui   existait  déjà,   il   est  nécessaire  d’expliquer  dans  un  premier  temps  le  mode  de  fonctionnement  de  la  base  de  données  et  d’en  détailler  le  contenu.  

 

3.1-­‐Définitions    La  base  de  données  associée  à  Vente  Partner  fonctionne  via  3  éléments  nécessaires  :  

la  vue,  la  famille  et  la  fiche.    

3.1.1-­‐Vue    Une   vue   équivaut   à   une   fenêtre   de   saisie.   Elle   regroupe   un   certain   nombre  

d’informations  comme  des  zones  de  saisie,  des  boutons  radio  ou  des  cases  à  cocher.  Chaque  vue  est  référencée  par  un  nom  unique.  Sa  taille  est  variable  mais  elle  ne  peut  

pas  dépasser  la  résolution  d’un  écran.  Ainsi,  pour  une  meilleure  visualisation,  plusieurs  vues  peuvent  être  ajustées  côte  à  côte.  

 

3.1.2-­‐Famille    Une   famille  correspond  à  une  table.  Elle  est   le  plus  souvent  constituée  d’une  seule  

vue  mais  il  est  possible  d’y  associer  un  nombre  illimité.  Il  existe  2  cas  particuliers  de  famille  :  -­‐   famille  ancêtre  :   c’est  une   famille  située  à  un  niveau  supérieur  par  rapport  à  une  

autre  famille  ;  -­‐  famille  principale  :  c’est  une  famille  de  premier  niveau  donc  n’ayant  pas  d’ancêtre  ;  

elle  comporte  en  général  des  informations  uniques.    

3.1.3-­‐Fiche    Une  fiche  équivaut  à  une  ligne  d’une  table.  L’affichage  de  la  fiche  (ou  d’une  partie  de  

celle-­‐ci)  se  fait  au  travers  d’une  vue.  Chaque  fiche  a  une  clé  unique,  une  clé  primaire,  appelé  «  sys-­‐id  »  :  elle  est  créée  par  

Vente  Partner.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  12  -­‐  

   

3.2-­‐Base  de  données    La  base  de  données  de  la  version  à  modifier  de  la  GRC  a  la  même  architecture  chez  

Avenir  Bureautique  et  Sigec.    Chaque  famille  est  liée  à  une  seule  vue,  à  l’exception  des  familles  «  Menu  »  (8  vues)  

et  «  Société  »  (5  vues).  La   famille   «  Menu  »   est   un   ensemble   de   vues   permettant   soit   d’aller   vers   une   ou  

plusieurs  autres  vues  soit  de  lancer  des  traitements  comme  des  éditions  ou  des  exports  de  données  :  il  ne  s’agit  donc  pas  stricto  sensu  d’une  vraie  table.  

En   revanche,   dans   la   mesure   où   la   famille   «  Société  »   est   une   table   englobant   de  nombreux  champs  d’information,  il  ne  faut  pas  tous  les  disposer  dans  une  seule  vue  au  risque  de  la  rendre  illisible.  Ainsi,  cette  famille  a  été  scindée  en  plusieurs  vues  dont  les  plus  importantes  sont  :  

-­‐   vue   «  Identification  »   contenant   les   renseignements   les   plus   significatifs   d’une  entreprise  comme  sa  raison  sociale,  son  adresse  et  son  numéro  de  téléphone  ;  

-­‐   vue   «  Autres   informations   Société  »   intégrant   des   éléments   administratifs   d’une  société  comme  le  numéro  SIRET,  le  code  NAF,  la  forme  juridique  ou  le  chiffre  d’affaire.  

 L’arborescence   ci-­‐dessous   (Figure   3)   montre   l’architecture   des   familles   sur   3  

niveaux  mais  il  peut  y  en  avoir  plus.  Celle-­‐ci  respecte  un  protocole  «  père/fils/petit-­‐fils  ».  Dans  la  base  de  données  actuelle,  la  table  «  Société  »  est  le  père,  la  table  «  Parc  »  est  à  la  fois  fils  et  père,  et  la  table  «  Relance  »  est  à  la  fois  fils  et  petit-­‐fils.  

Quelle  est  la  justification  d’une  telle  organisation  ?  En   fait,   être   à   l’intérieur  d’une   vue  ou  d’un   traitement  donne   l’autorisation  d’aller  

récupérer   des   champs   dans   une   autre   vue   sans   passer   par   d’autres   fonctionnalités.  Toutefois,   ce   système   a   des   limites.   En   effet,   un   fils   peut   «  voir  »   un   père   mais   pas  l’inverse.   Ainsi,   la   vue   «  Relance  »   peut   accéder   aux   champs   des   vues   «  Parc  »   et  «  Identification  »  tandis  que  «  Parc  »  ne  peut  accéder  qu’à  ceux  de  «  Société  ».  De  même,  il   est   impossible   à   2   vues   ou   familles   de  même   niveau   hiérarchique   d’atteindre   leurs  zones  de  données  respectives  :  pour  y  arriver,  elles  doivent  passer  par  une  jointure.  La  jointure  se   fait  grâce  à   la  présence  dans   l’une  des  2  d’un  champ  commun  équivalent  à  une  clé  étrangère.  

           

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  13  -­‐  

 

 Fig.  3  :  Arborescence  des  familles  

   

3.3-­‐Diagramme  de  classes    Le   diagramme   de   classes,   détaillé   ci-­‐dessous   (Figure   4),   est   basé   sur   les   familles  

employées  par  les  différents  utilisateurs  d’Avenir  Bureautique  et  Sigec  qui  sont  :  -­‐  «  Société  »  ;  -­‐  «  Action  »  ;  -­‐  «  Affaire  »  ;  -­‐  «  Contact  »  ;  -­‐  «  Parc  ».    La  famille  «  Société  »  est  à  la  fois  une  famille  ancêtre  et  une  famille  principale  donc  

les  4  autres  familles  sont  directement  liées  à  elle.  La  vue  «  Action  »  peut  se  rapporter  :  -­‐  soit  aux  vues  «  Contact  »  et  «  Action  »  ;  -­‐  soit  à  l’une  des  2  ;  -­‐  soit  à  aucune  des  2.  De  même,  la  vue  «  Affaire  »  peut  concerner  la  vue  «  Contact  »  ou  non.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  14  -­‐  

 En  revanche,  la  vue  «  Commercial  »  doit  toujours  être  associée  aux  vues  «  Affaire  »  et  

«  Action  ».    

 Fig.  4  :  Diagramme  de  classes  de  l’existant  

   

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  15  -­‐  

 

4-­‐Le  développement    Dans  cette  partie,   je  détaille  chronologiquement   les  différentes  actions  entreprises  

au  niveau  du  développement  de  la  GRC.    

4.1-­‐Cahier  des  charges    Le   cahier   des   charges   a   été   pensé   et   constitué   par   Mrs   Rodolphe   ALBEROLA   et  

Fredéric  CHARANSOL  afin  qu’il  soit  commun  aux  2  sociétés.  La  première  étape  consiste  à  modifier  plus  ou  moins  profondément   les  différentes  

vues   employées   par   les   commerciaux   pour   leur   travail   quotidien.   Cela   concerne   les  vues  :  

-­‐  «  Identification  »  ;  -­‐  «  Autres  informations  Société  »  ;  -­‐  «  Action  »  ;  -­‐  «  Affaire  »  ;  -­‐  «  Contact  »  ;  -­‐  «  Parc  ».  En   second   lieu,   il   s’agit  de   trier   les   traitements  existants   (liste  de   travail,   éditions,  

exports,   graphiques,…)   afin   de   garder   ceux  nécessaires   et   donc   les   remanier   selon   les  changements  apportés  aux  vues  qui  leur  sont  liées.  

Enfin,   la   dernière   étape   passe   par   un   relooking   de   l’interface   jugée   trop   terne   et  ayant  un  design  des  années  1990.  

 Dans   la   logique  de   travail  des  2  sociétés,  beaucoup  de  réunions  se   font  à   l’aide  de  

documents   Word   ou   Excel   qui   sont   composés   d’informations   piochées   dans   les  différentes   vues   de   Vente   Partner  :   la   mise   à   jour   des   vues   et   des   traitements   doit  permettre  de  toujours  passer  par  la  GRC  uniquement.  

 

4.2-­‐Premiers  jours  de  stage    Avant  de  commencer  à  détailler  ma  phase  de  développement,  il  convient  de  fournir  

des  informations  sur  mes  premiers  jours  du  stage.    Outre   la   visite   du   siège   social   et   ma   présentation   au   personnel,   j’ai   reçu   une  

formation  condensée  de  développeur/administrateur  sur  Vente  Partner  de  la  part  de  Mr  Bertrand  ELINEAU  de  Technomade  durant  3  jours  pour  me  familiariser  avec  la  GRC.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  16  -­‐  

 Ensuite,   afin   que   toutes   les   agences   d’Avenir  Bureautique   puissent   avoir   la  même  

base   de   données,   il   a   été   nécessaire   d’intégrer   des   bases   de   données   qui   étaient  employées  à  part  via  des  imports.  

De   plus,   il   a   fallu   installer   la   version   12.0   du   logiciel   sur   tous   les   postes   existants  ainsi  que  sur  les  nouveaux.  

Enfin,   il   fut  décidé,  en  accord  avec  Mr  Rodolphe  ALBEROLA,  que  le  développement  se   ferait   graduellement   par   plusieurs   mises   à   jour   de   la   GRC   au   sein   d’Avenir  Bureautique  afin  d’habituer  les  commerciaux  au  maniement  de  ce  nouvel  outil  et  d’avoir  des  retours  de  son  emploi.  

 

4.3-­‐Consolidations    Il  est  primordial  d’expliquer  ce  qu’est  une  consolidation.    Chaque  agence  d’Avenir  Bureautique  possède  son  propre  serveur  où  chaque  poste  

est   connecté   pour   accéder   à   la   base   de   données   de   Vente   Partner,   le   serveur   de  Besançon  faisant  office  de  serveur  central  (il  en  est  de  même  pour  Sigec).  Comme  la  base  de   données   doit   être   identique   sur   chaque   serveur,   il   faut   que   des   consolidations  s’effectuent  entre  chaque  site.  

 Une   consolidation  donne   la  possibilité  d’échanger  des  données  entre   serveurs  par  

des   transferts   de   fichiers   en   protocole   FTP.   Un   script   permet,   sur   chaque   serveur,   de  récupérer,  pour  chaque   famille,   les   fiches  qui  ont  été   créées,  modifiées  ou  supprimées  durant  les  3  derniers  jours  en  les  intégrant  dans  un  fichier.  Ainsi,   le  serveur  central  de  Besançon  doit  constituer  3  fichiers  à  chaque  consolidation  pour  le  site  de  Dijon,  celui  de  Montbéliard  et  un  portable  en   licence  monoposte   c’est-­‐à-­‐dire  ayant   sa  propre  base  de  données   (comme   celui   que   j’ai   employé   pour   le   développement).   Chaque   fichier   de  consolidation  élaboré  est  déposé  dans  un  répertoire  de  destination  avant  d’être  envoyé  (ce   fichier   arrive   dans   un   répertoire   de   destination).   Ce   même   script   (ou   un   autre)  s’occupe   de   la   réception   en   faisant   l’inverse   de   ce   qui   vient   d’être   détaillé.   Les  consolidations   s’effectuent   2   fois   par   jour  :   la   période   du   déjeuner   et   le   soir.   Ces  consolidations  sont  appelées  consolidation  de  données.  

               

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  17  -­‐  

 

 Fig.  5  :  Description  de  la  consolidation  de  données  

 Il   existe   également   la   consolidation   système  :   il   s’agit   d’une   consolidation   de  

données   à   laquelle   a   été   ajouté   l’environnement   système   de   la   GRC.   Ainsi,   je   passais  toujours  par  celle-­‐ci  pour  transférer  sur  les  autres  sites  les  mises  à  jour  déployées  sur  le  serveur  de  Besançon.  En  revanche,  cela  devait  toujours  se  faire  après  une  consolidation  de  données.  

 Le   principe   des   consolidations   occasionne   plusieurs   problèmes.   Le   débit   internet  

des   sites   de   Dijon   et   de   Montbéliard   étant   assez   faible   et   variable,   un   fichier   de  consolidation   pouvait   toujours   être   en   train   d’être   expédié   alors   que   le   script   de  réception  à  Besançon  s’était  déjà  achevé  ce  qui  occasionne  un  retard  de  mise  à  jour  de  la  base  de  données.  Ce  problème  est  identique  pour  des  consolidations  de  grande  taille.  De  plus,   celles  qui  s’effectuent  durant   la  période  du  déjeuner  gênent   les  commerciaux  car  Vente  Partner  ne  doit  pas  être  employé.  Finalement,   la   solution  à   ces  ennuis   sera   très  vraisemblablement   de   supprimer   la   consolidation   de   mi-­‐journée   et   de   profiter  pleinement  de  la  nuit  pour  actualiser  les  bases  de  données.  

 

4.4-­‐Groupes  d’accès  et  utilisateurs    Par   souci   de   sécurité   et   de   rationalisation,   il   a   été   nécessaire   de   revoir   les   noms  

d’utilisateur  des  usagers  de  la  GRC  ainsi  que  les  groupes  d’accès.  Chaque  nom  d’utilisateur  est  défini  sur  3  chiffres,  le  premier  désignant  le  site  (chez  

Avenir  Bureautique,  6xx  pour  Besançon,  7xx  pour  Dijon  et  8xx  pour  Montbéliard).  Un  groupe  d’accès  contient  1  ou  plusieurs  utilisateurs.  Il  permet  d’autoriser  ou  non  

l’accès  à  des  champs  de  saisie,  des  vues  ou  des  traitements  ainsi  que  l’ajout,  la  création  et  la  modification.  Par  exemple,  seuls  les  groupes  «  Administrateurs  »,  «  Chefs  vente  »  et  «  Superviseurs  »  ont  le  droit  de  modifier  le  contenu  de  la  liste  d’aide  du  champ  de  saisie  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  18  -­‐  

«  Fournisseur  en  place  »  dans  la  vue  «  Parc  »  ce  qui  permet  d’avoir  des  données  uniques  et   compréhensibles   pouvant   servir   comme   critère   de   tri   sinon   un   même   fournisseur  pourrait  avoir  de  nombreuses  orthographes  différentes.  

L’application  «  Outils  »  livrée  avec  Vente  Partner  a  été  employée  pour  effectuer  ces  changements.  

 

4.5-­‐Vues    La   vue   est   la   pierre   angulaire   de   l’emploi   de   la   GRC   et   donc   la   partie   la   plus  

importante  du  développement.  Toutes   les   créations   ou   modifications   de   vue   se   font   via   l’application   «  Ecrans  »  

fournie  avec  Vente  Partner.  Comme  expliqué  plus  en  avant  du  rapport,  une  vue  est  une  fenêtre  regroupant  des  

zones   d’information   ou   de   saisie.   Il   existe   un   certain   nombre   de   ces   zones   sous  «  Ecrans  ».  En  mettant  de  côté  les  plus  communes  à  tout  autre  logiciel  comme  les  libellés,  cases   à   cocher,   bouton   radio   et   mémo,   je   vais   m’attarder   sur   celles   qui   furent   très  importantes  dans  le  processus  de  mise  en  forme  de  chaque  vue.  

 

 Fig.  6  :  Descriptif  de  zones  sur  la  vue  «  Affaire  »  

 

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  19  -­‐  

 

4.5.1-­‐Objet  saisie    L’objet   saisie  est  une  zone  de   saisie  ou  éventuellement  une  zone  d’information  de  

taille  fixe.  Chaque  objet  saisie  d’une  vue  doit  porter  un  nom  unique  et  possède  un  type  de  zone  comme  l’alphanumérique  par  exemple.  En  revanche,  le  type  de  zone  est  définitif  à  sa  création.  

Il  est  possible  d’interdire   la  saisie  (la  zone  se  transforme  alors  en   information),  de  l’autoriser  sous  certains  facteurs  et  d’en  vérifier  le  contenu  sous  plusieurs  conditions.  Le  contenu  de  champ  de  saisie  peut  être  initialisé  selon  certains  critères  ou  via  une  formule.  Cette  formule  est  composée,  soit  d’une  ou  plusieurs  autres  zones  provenant  de  la  même  vue   (et/ou   de   sa   vue   «  père  »),   soit   d’une   ou   plusieurs   fonctions   prédéfinies   de  Vente  Partner,   soit  d’un  amalgame  des  2.  Toutefois,   le  peu  de  maniabilité  de  ces   fonctions  et  l’impossibilité  d’accéder  à  d’autres  vues  rendent  ardu  le  choix  des  formules.  Il  est  à  noter  que  le  système  des  formules  fonctionne  aussi  pour  l’autorisation  d’atteindre  une  zone.  

Enfin,  un  objet  peut  être  visible  ou  caché.    Il   existe   une   option   à   l’objet   saisie  :   c’est   la   liste   d’aide.   La   liste   d’aide   est   un  

ensemble  de  données  fournissant  un  choix  de  sélection.  Si  le  champ  est  interdit  en  saisie,  l’utilisateur  pourra  et  peut-­‐être  devra  y  piocher  dedans  pour  remplir  la  zone.  Si  elles  ne  sont   pas   saisies   manuellement,   les   informations   à   l’intérieur   d’une   liste   d’aide  proviennent  soit  d’une  autre  vue  soit  d’une  autre  liste  d’aide.  L’affichage  du  contenu  de  la   liste   peut   révéler   un   ou   plusieurs   champs.   De  même,   le   résultat   de   la   sélection   se  trouvant  maintenant  dans  l’objet  saisi  peut  être  une  concaténation  de  plusieurs  champs.  De  plus,  le  choix  réalisé  par  l’utilisateur  peut  très  bien  faire  afficher  des  valeurs  d’autres  champs  de  cette  même  liste  dans  d’autres  zones  de  la  même  vue.  

 Comme  il  était  demandé  dans  le  cahier  des  charges,  de  nombreuses  listes  d’aides  ont  

été   intégrées   à   des   objets   saisie.   Celles-­‐ci   sont   protégées   de   façon   à   ce   que   personne,  hormis   les   groupes   d’accès   autorisés,   ne   puisse   en  modifier   le   contenu.   En   outre,   les  zones  de  saisie  des  objets  qui  leurs  sont  associées  sont  verrouillées  en  écriture  dans  le  but  d’avoir  seulement  les  vraies  données  utiles  pour  des  traitements.  

Cependant,   plusieurs   problèmes   sont   apparus.   D’une   part,   les   changements   dans  une  liste  d’aide  dont  le  contenu  ne  provient  pas  d’une  vue  ne  seront  effectifs  que  sur  le  serveur   où   elle   se   trouve.   Pour   que   ces  modifications   soient   prises   en   compte   sur   les  autres  serveurs,  il  faut  à  chaque  fois  exécuter  une  consolidation  système.  D’autre  part,  il  apparaît  que   la  même   liste  d’aide  peut  se  retrouver  sur  2  vues  différentes.  Pour  palier  ces  difficultés,  il  a  été  décidé  de  transformer  ces  listes  d’aide  en  nouvelles  vues  facilitant  ainsi  une  mise  à   jour  rapide  des  données  sur  chaque  site  et  évitant   les  duplicatas.  Par  exemple,  la  liste  d’aide  des  fournisseurs  présente  dans  la  vue  «  Parc  »  était  identique  à  la  liste  des  concurrents  dans  la  vue  «  Affaire  »  :  cette  liste  est  devenue  la  vue  «  Entreprise  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  20  -­‐  

concurrente  ».   De  même,   les  modèles   d’une  marque   changeant   fréquemment,   une   vue  «  Modèle  »  a  été  créée  également.  

 

4.5.2-­‐Bouton  action    Un   bouton   action,   tout   comme   un   objet   saisie,   porte   un   nom   unique   et   son   accès  

peut  être  autorisé  ou  non  à  certaines  catégories  de  personnel.  Il  peut  aussi  intégrer  du  texte   et/ou   une   image   comme   représentation   visuelle.   Il   permet,   entre   autre,   de  déclencher  un  traitement,  d’exécuter  une  application  externe  comme  accéder  à  un  site  internet,  de  naviguer  vers  une  autre  vue  ou  d’exécuter  un  enchainement  (par  exemple,  effectuer  un  export  de  données  et  l’ouvrir  avec  Microsoft  Excel).  

 Les  boutons  existants  aidaient  déjà  à  réaliser  ces  fonctions.  Le  bouton  de  recherche  

symbolisé  par  une  paire  de  jumelles  et  ceux  de  déplacement  d’une  fiche  à  un  autre  ont  été   généralisés   sur   toutes   les   vues   les   plus   importantes.   Plusieurs   boutons   ont   été  conçus  dans  le  but  de  rentrer  sur  des  sites  internet  ou  sur  des  applications  réseau.  Dans  le  cas  des  liens  avec  des  sites  internet,  des  scripts  ont  été  élaborés  incluant  l’url  du  site.  

 

4.5.3-­‐Objet  externe    L’objet  externe  reprend  les  mêmes  principes  que  le  bouton  action  sauf  qu’il  permet  

de  stocker  des  fichiers  dans  une  fiche  d’une  vue.  Néanmoins,  seule  une  copie  du  fichier  a  été  faite  :  il  ne  s’agit  en  aucune  façon  d’un  raccourci  vers  celui-­‐ci.  

 Des  boutons  de  dépôt  de  pièces  jointes  ont  été  conçus  et  positionnés  dans  les  vues  

«  Identification  »,  «  Affaire  »  (les  devis  par  exemple)  et  «  Action  »  (les  comptes-­‐rendus  de  visite  par  exemple).   Il  a  été   fortement  conseillé  aux  utilisateurs  de  ne  déposer  que  des  documents   au   format   PDF   pour   éviter   de   trop   alourdir   la   base   de   données   et  d’augmenter  le  temps  de  transfert  du  fichier  de  consolidation  de  données  d’un  site  vers  un  autre.  

 

4.6-­‐Agenda    L’agenda   est   une   fonction   propre   à   Vente   Partner   permettant   à   un   utilisateur   de  

composer  son  propre  emploi  du  temps.  Pour  fonctionner,  l’agenda  doit  obligatoirement  être  associé  à  une  vue  :  ici,  il  est  liée  à  la  vue  «  Action  ».  Ainsi,  tout  ce  qui  est  réalisé  dans  la   vue   «  Action  »   se   retrouve   dans   l’agenda   et   vice   versa.   De   fait,   seules   certaines  données  nécessaires   à   la   création  et   à   l’affichage   apparaissent  dans   l’agenda  :   celles-­‐ci  ont  été  associées  à  certains  champs  de  la  vue  «  Action  »  dans  l’application  «  Ecrans  ».  

 

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  21  -­‐  

 Il   convient   de   différencier   2   types   d’élément   nécessaire   pour   qu’une   action   se  

retrouve  dans  l’agenda  :  -­‐   la   tâche  :   c’est   une   action   dans   le   temps   qui   apparaîtra   toujours   en   information  

jusqu’à  sa  date  d’échéance  ;  -­‐   l’évènement  :  c’est  une  action  ponctuelle  qui  a  une  date  et  une  heure  de  début,  et  

une  date  et  une  heure  de  fin  (par  exemple,  un  rendez-­‐vous).    Chaque  utilisateur  de  l’agenda  a  la  possibilité  de  :  -­‐  définir  des  horaires  de  travail  (affichés  en  couleur  bleu  ciel)  ;  -­‐  définir  l’affichage  de  ses  évènements  (jour,  semaine,  mois,  …)  ;  -­‐  définir  des  plages  horaires  de  15  minutes  à  4  heures.    

 Fig.  7  :  Exemple  de  l’agenda  d’un  commercial  

 Enfin,   l’agenda   planifié   sous   Vente   Partner   peut   se   retrouver   dans   Microsoft  

Outlook.    Lors  de  l’installation  de  la  version  12.0  du  logiciel,  2  options  ont  été  installées  afin  

de  faire  le  lien  entre  l’agenda  et  Microsoft  Outlook  :  -­‐  un  plug-­‐in  pour  Outlook;  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  22  -­‐  

-­‐  une  synchronisation  entre  Outlook  et  l’agenda.  Cependant,   il   convient   de   noter   que   seules   les   données   venant   de   l’agenda   iront   vers  Outlook  et  non  l’inverse.  

 Suite  aux  modifications  apportées  dans   la  vue  «  Action  »,   il  a   fallu  que   je  refasse   le  

lien   entre   les   champs   de   cette   vue   et   les   champs   obligatoires   pour   l’agenda.   Certains  champs   concernant   le   contact   n’étaient   pas   employés  :   comme   un   contact   peut   être  intégré  dans  une  action,  j’y  ai  ajouté  les  champs  nécessaires  (champs  «  Civilité  »,  «  Nom  »  et   «  Prénom  »   de   la   vue   «  Action  »).   En   outre,   il   a   fallu   aussi   redéfinir   les   différentes  catégories   afin   de   les   faire   coïncider   avec   les   données   de   la   liste   d’aide   du   champ  «  Type  »  de  la  vue  «  Action  ».  

 Enfin,   certains   types   d’action,   jugés   plus   importantes   que   les   autres,   furent   dotés  

d’un  code  couleur  dans  le  but  de  les  faire  ressortir  dans  l’agenda.    

4.7-­‐Traitements    Les   traitements  sont  des  procédés  de  manipulation  du  contenu  d’une  ou  plusieurs  

tables  pour  afficher  ou  échanger  des  données.  L’application  «  Traitements  »,  livrée  avec  Vente  Partner,  permet  de  les  gérer.  

Bien   qu’il   y   en   ait   un   certain   nombre,   la   nouvelle   mouture   de   la   GRC   emploie  surtout  :  

-­‐  les  listes  de  travail  ;  -­‐  les  éditions  ;  -­‐  les  dossiers  ;  -­‐  les  exports  ;  -­‐  les  graphiques  ;  -­‐  les  étiquettes.    Comme   je   l’ai   expliqué  dans   le   chapitre  précédent,   le  problème  réside   toujours  en  

cette  hiérarchie  des   familles  n’autorisant  pas   l’amalgame  de  plusieurs  vues  ou  familles  en  une  seule  somme.  Cette  difficulté  apparaît  encore  plus  dans  les  traitements.  Ainsi,  des  choix  ont  du  être  effectués  pour  palier  ce  problème,  soit  par  l’ajout  d’un  champ  de  type  clé   étrangère   dans   une   vue   pour   accéder   aux   informations   d’une   autre,   soit   par   la  restriction  des   informations  visibles   lors  du  résultat.   Il  est   toutefois  utile  de  noter  que  tous  les  traitements  ont  un  point  commun  :  la  possibilité  d’insérer  des  critères  de  tri  afin  de  filtrer  les  valeurs  d’une  ou  plusieurs  vues.  

       

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  23  -­‐  

 

 Fig.  8  :  Création  des  critères  tri  et  visualisation  de  ceux-­‐ci  

 

4.7.1-­‐Listes  de  travail    La  liste  de  travail  est  le  résultat  d’une  recherche  affichée  sous  le  format  d’une  liste.  

Un  simple  clic  sur  une  ligne  de  celle-­‐ci  permet  d’accéder  directement  à  la  vue  associée,  la  liste  se  refermant  temporairement  en  une  icône.  Les  champs  de  visualisation  de  la  liste  sont  définis   lors  de  sa  création  mais  peuvent  être  changés  à  tout  moment  car   la   liste  a  été  créée  à  partir  d’une  vue.  

 Toutes   les   listes   de   travail   ont   été   supprimées   car   elles   ne   répondaient   pas   aux  

attentes   des   personnels   d’Avenir   Bureautique   et   Sigec   et   donc   seules   des   nouvelles  apparaissent  dans  la  nouvelle  mouture  de  la  GRC.  

                       

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  24  -­‐  

 

 Fig.  9  :  Exemple  de  liste  de  travail  

   

4.7.2-­‐Editions    L’édition  est  le  résultat  d’une  recherche  par  critères  de  tri  sur  une  ou  plusieurs  vues  

pouvant  être  imprimé.  Elle  est  constituée  d’un  amalgame  d’une  ou  plusieurs  des  parties  suivantes  :  -­‐  entête  ;  -­‐  haut  page  ;  -­‐  rupture  haut  ;  -­‐  corps  ;  -­‐  rupture  bas  ;  -­‐  bas  page  ;  -­‐  pied  ;  -­‐  graphique.    L’entête  n’apparaît  qu’une  seule  fois  au  tout  début  de  la  première  page.  Le  haut  de  

page  sera  présent  en  haut  de  chaque  page,   le  bas  de  page  en  bas  de  chaque  page  et   le  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  25  -­‐  

corps   toujours  au  centre  de  chaque  page.  Le  pied  permet  de   faire   la  somme  totale  des  différents   champs   numériques   présents   dans   les   autres   parties.   Le   graphique   est   un  graphe.  Les  ruptures  n’existent  que  si  les  données  des  champs  servant  pour  des  critères  de   tri   sont   classées   de   façon   ascendante   ou   descendante.   Elles   permettent   de   faire   la  séparation   entre   chaque   groupe  de  données  disposé  dans   le   corps.   Par   exemple,   pour  une  édition  du  parc  machine,  la  rupture  peut  être  faite  sur  une  société.  

 

 Fig.  10  :  Exemple  de  disposition  dans  une  édition  

 De  nombreuses  éditions  ont  été  remaniées  ou  crées,  les  autres  étant  laissées  de  côté.  

Le  seul  problème  est  venu  du  système  de  rupture  qui  n’autorisait  pas  de  pouvoir   faire  plus   que   2   critères   de   tri   ascendant   ou   descendant  :   des   projets   d’éditions   plus  sophistiquées  et  détaillées  ont  dû  être  abandonnés.  

 

4.7.3-­‐Dossiers    Le  dossier  regroupe  un  ensemble  d’éditions.   Il   intègre  aussi  une  édition  contenant  

un  haut  de  page  et  un  bas  de  page  qui  se  transforme  en  bloc  de  haut  de  page  et  bloc  bas  de  page,  ces  2  blocs  s’affichant  toujours  en  haut  de  page  et  bas  de  page  de  chaque  édition  constituant  le  dossier.  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  26  -­‐  

 

 Fig.  11  :  Exemple  de  définition  d’un  dossier  

 Les   dossiers   existants   ont   été   remaniés   de   façon   à   intégrer   les   nouvelles   éditions  

réalisées.    

4.7.4-­‐Exports    L’export  est  la  récupération  des  valeurs  d’une  ou  plusieurs  vues  sous  le  format  d’un  

fichier   exploitable   par   des   applications   sous   Microsoft   Windows.   Les   valeurs   sont  regroupées  par  champ.  

 Plusieurs  exports  ont  été  conçus  et  intégrés  dans  des  boutons  de  type  action  dans  la  

vue   «  Menu  ».   Chacun   de   ces   boutons   effectue   aussi,   après   la   création   de   l’export,   le  lancement  du  logiciel  Microsoft  Excel.  

 

4.7.5-­‐Graphiques    Le  graphique  est  une   représentation   sous   forme  de  graphe  d’une  zone  numérique  

provenant  soit  d’un  champ  au  format  numérique  d’une  vue  soit  d’un  calcul.  Il  est  ajouté  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  27  -­‐  

dans  une  édition  :   ce   sont   les   informations  de   cette  dernière  qui   sont   employées  pour  celui-­‐ci.  

Plusieurs  représentations  sont  disponibles  :  -­‐  par  colonne  ;  -­‐  par  courbe  ;  -­‐  par  aire  ;  -­‐  par  barre  ;  -­‐  par  secteur.    Seul  un  seul  graphique  de  type  secteur  a  été  conçu.    

4.7.6-­‐Etiquettes    

L’étiquette   est   une   édition   simple   (sans   entête,   corps,   rupture   ou   bas   de   page)  prévue   pour   un   format   de   feuille   précis   portant   des   étiquettes   autocollantes  prédécoupées.  Chaque   résultat  des   critères  de   tri   associés  est   imprimé  sur  une  de   ces  zones   prédécoupées.   Plusieurs   formats   prédéfinis   sont   intégrés  mais   il   est   tout   à   fait  possible  d’en  personnaliser  un  autre.  

 

 Fig.  12  :  Définition  d’une  étiquette  

 Il  existait  une  édition  simple  de  type  étiquette  qui  a  été  gardée,  seuls  de  nouveaux  

critères   de   tri   y   ont   été   ajoutés.   Pour   information,   le   format   employé   chez   Avenir  Bureautique  et  Sigec  n’apparaissant  pas  dans  les  formats  prédéfinis  de  Vente  Partner,  il  avait   été   personnalisé   (étiquette   largeur   70mm,   hauteur   37mm,   8   rangées   pour   3  colonnes).  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  28  -­‐  

 

4.8-­‐Relooking    Le  relooking  s’est  surtout  concentré  sur  le  remplacement  des  icônes  et  images  trop  

vieillottes  et   trop  pixélisées.  De  même,   les   fonds  gris   terne  des  vues  ont  été  remplacés  par  une  texture  de  fond  unique  pour  toutes.  Tous  les  boutons  permettant  d’accéder  aux  vues  ou  à  des  traitements  ne  servant  plus  ont  été  cachés.  

 

4.9-­‐Tâches  annexes    Tous  les  commerciaux  se  retrouvent  une  fois  par  mois  au  siège  social  dans  le  but  de  

procéder   à   une   relance   groupée   sur   les   prospects.   Cette   relance   s’effectue   via   des  éditions  contenant  un  minimum  d’informations.  

La   solution   serait   de   mettre   un   commercial   devant   chaque   ordinateur   équipé   de  Vente  Partner  pour  avoir  tous  les  renseignements  d’une  société  à  disposition  mais  peu  de  postes  sont  libres  pour  doter  chacun.  Finalement,  il  a  été  décidé  de  procurer  à  chaque  commercial   des   sites   de   Dijon   et   Montbéliard   un   ordinateur   portable   pouvant   se  connecter  aussi  bien  à   la  base  de  données  de  son  agence  que  celle  de  Besançon.  D’une  part,   un   technicien   de   Technomade   a   dû   intervenir   à   distance   de   façon   à   ce   que   le  nombre  maximum  d’ordinateurs  connectés  ensemble  au  serveur  passe  de  6  à  9.  D’autre  part,  j’ai  installé  la  GRC  sur  ces  nouveaux  matériels  ainsi  que  2  petits  scripts.  Chacun  de  ces   scripts   permet   d’accéder   au   serveur   d’un   site   bien   particulier.   Selon   le   lieu   où   se  trouve   la   machine,   l’utilisateur   devra   exécuter   le   bon   script   avant   le   lancement   du  logiciel.  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  29  -­‐  

 

Conclusion    N’ayant   toujours   connu   que   le   monde   militaire,   j’éprouvais   une   certaine  

appréhension   à   effectuer   un   stage   dans   une   entreprise.   Toutefois,   le   thème   fort  intéressant   du   projet   à   réaliser   et   l’accueil   chaleureux   du   personnel   d’Avenir  Bureautique  m’ont  totalement  rassuré  et  m’ont  permis  de  m’intégrer  très  facilement  au  sein  de  la  société.  

 A  l’issue  de  ces  14  semaines  intenses  et  riches  en  expériences,  je  peux  faire  un  bilan  

très  positif  de  cette  immersion  dans  le  monde  du  travail.  D’un   point   de   vue   humain,   je   suis   pleinement   satisfait   d’avoir   évolué   au   sein  

d’Avenir  Bureautique  qui  est  une  entreprise  très  structurée  et  d’y  ressentir  un  esprit  de  compétitivité   permanent   lui   permettant   de   pérenniser   sa   position   d’important   acteur  régional  dans  son  secteur  d’activité  tout  en  conservant  une  ambiance  de  travail  d’équipe  conviviale.  De  plus,   l’échange  d’idées   et   d’informations   s’est   toujours  bien  passé   entre  moi  et  d’une  part,  les  différents  acteurs  prenant  part  au  développement  de  l’application  et  d’autre  part,  les  utilisateurs  de  cette  nouvelle  mouture.  

D’un  point  de  vue  technique,  ce  séjour  m’a  permis  de  découvrir  un  environnement  logiciel   qui   m’était   totalement   inconnu   jusqu’à   ce   jour  :   la   GRC.   Bien   qu’ayant   eu   des  débuts   difficiles   malgré   une   formation   succincte   et   accélérée,   j’ai   réussi   à   me  l’approprier  et  à  en  connaître  les  principaux  rouages  me  permettant  ainsi  de  réaliser  un  outil  performant  au  service  de   la  chaine  commerciale  de   la  société.   Il  offre  maintenant  des  renseignements  très  détaillés  et   très  précis  sur   les  clients  ou   les  prospects.  Certes,  elle  aurait  eu  besoin  d’autres  améliorations  mais  elle  a  été  suffisamment  actualisée  pour  rester  en  service  encore  plusieurs  années.  

 Finalement,   ce   stage   au   sein   d’Avenir   Bureautique   aura   été   une   aventure   très  

enrichissante  aussi  bien  sur  le  plan  humain  que  sur  le  plan  technique.  Cette  aventure  se  termine  donc  mais   une   autre   commence.   En   effet,   la   semaine   suivante   la   fin   du   stage,  j’intégrerai  une  équipe  de  développement  au  sein  d’Axess  Vision,   toujours  à  Besançon,  afin   de   concevoir   une   GED   pouvant   ensuite   être   proposée   à   leurs   clients   par   les  commerciaux  d’Avenir  Bureautique  et  Sigec.  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  30  -­‐  

 

Glossaire    FTP  (sigle  pour  File  Transfer  Protocol)  C’est  un  protocole  de  communication  destiné  à  l’échange  informatique  de  fichiers  sur  un  réseau  TCP/IP.  

 NAF  (sigle  pour  Nomenclature  d’Activités  Françaises)  Elle   représente,   par   un   code,   l’activité   principale   exercée   dans   une   entreprise   ou   une  association.  

 QBE  (sigle  pour  Query  By  Example)  En  français,  cela  se  traduit  par  interrogation  par  l’exemple.  Son  principe  est  que  l’utilisateur  présente  un  exemple  du  résultat  de  recherche  attendu  puis  le  soumet  au  SGBD.  

 SGBD  (sigle  pour  Système  de  Gestion  de  Base  de  Données)  En   informatique,   c’est   un   logiciel   système   destiné   à   stocker   et   à   partager   des  informations   dans   une   base   de   données   qui   est   un   ensemble   d’informations   stockées  dans  un  dispositif  informatique.  

 SIRET  (sigle  pour  Système  d’Identification  du  Répertoire  des  Etablissements)  Il  s’agit  d’un  identifiant  géographique  d’un  établissement  ou  d’un  entreprise  codé  sur  14  chiffres.  

 SQL  (sigle  pour  Structured  Query  Language)  C’est  un  langage  informatique  normalisé  servant  à  effectuer  des  recherches,  des  ajouts,  des  modifications  ou  des  suppressions  de  données  dans  une  base  de  données.  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  31  -­‐  

 

Webographie      

Avenir  Bureautique       http://www.avenirbureautique.fr/    KDP  Informatique       http://www.kdp-­‐info.com  

 Sage  Group         http://www.sage.fr/  

 Sigec           http://www.sigec-­‐bureautique.com/  

 Technomade         http://www.technomade.com/  

 Wikipédia         http://fr.wikipedia.org  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  32  -­‐  

 

Annexes    

Annexe  A  :  L’ancienne  mouture  de  la  GRC    

 Page  d’accueil  de  Vente  Partner  composée  de  la  vue  «  Menu  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  33  -­‐  

   

 Vue  «  Menu  relances  »  accessible  depuis  la  vue  «  Menu  »  

   

 Vue  «  Editions  »  accessible  depuis  la  vue  «  Menu  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  34  -­‐  

   

 Vue  «  Tables  des  paramètres  »  accessible  depuis  la  vue  «  Menu  »  

   

 Vue  «  Commercial  »  accessible  depuis  la  vue  précédente  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  35  -­‐  

   

 Vue  «  Identification  »  accessible  depuis  la  vue  «  Menu  »  

   

 Vue  «  Autres  informations  Société  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  36  -­‐  

   

 Vue  «  Heures  de  visite  »  accessible  depuis  la  vue  «  Identification  »  

   

 Vue  «  Contact  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  37  -­‐  

   

 Vue  «  Action  »  accessible  depuis  la  vue  «  Identification  »  

   

 Vue  «  Affaire  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  38  -­‐  

   

 Vue  «  Offre  »  accessible  depuis  la  vue  «  Identification  »  

(vue  non  modifiée)      

 Vue  «  Parc  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  39  -­‐  

 

Annexe  B  :  Le  cahier  des  charges    

 Nouvelle  vue  «  Identification  »  

   

 Nouvelle  vue  «  Contact  »  

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  40  -­‐  

 

 Nouvelle  vue  «  Parc  »  

   

 Nouvelle  vue  «  Action  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  41  -­‐  

   

 Nouvelle  vue  «  Affaire  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  42  -­‐  

   

 Exemple  de  future  liste  d’aide  pour  la  nouvelle  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  43  -­‐  

   

 Exemple  de  future  liste  d’aide  pour  la  nouvelle  vue  «  Identification  »  

         

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  44  -­‐  

 

Annexe  C  :  La  nouvelle  mouture  de  la  GRC    

 Page  d’accueil  de  VenteParter  composée  de  la  vue  «  Menu  »  

   

 Vue  «  Tables  de  paramètres  »  accessible  depuis  la  vue  «  Menu  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  45  -­‐  

   

 Vue  «  Identification  »  accessible  depuis  la  vue  «  Menu  »  

   

 Vue  «  Autres  informations  Société  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  46  -­‐  

   

 Vue  «  Heures  de  visite  »  accessible  depuis  la  vue  «  Identification  »  

   

 Vue  «  Contact  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  47  -­‐  

   

 Vue  «  Action  »  accessible  depuis  la  vue  «  Identification  »    

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  48  -­‐  

 Vue  «  Affaire  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  49  -­‐  

   

 Vue  «  Parc  »  accessible  depuis  la  vue  «  Identification  »  

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  50  -­‐  

 

Annexe  D  :  Exemple  d’éditions    

   

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  51  -­‐  

   

   

     

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  52  -­‐  

   

   

   

                               Développement  et  déploiement  d’une  GRC                                  

   

-­‐  53  -­‐  

 

Résumé    La   licence   professionnelle   «  Systèmes   Informatiques   et   Logiciels   spécialité  

Conception   et   Développement   Orientés   Objet   d'Applications   Multi-­‐tiers  »dispensé   à  l’Université  de  Franche-­‐Comté  de  Besançon  durant  une  année  universitaire  est  validée  par  l’intermédiaire  d’un  stage  en  entreprise  d’une  durée  de  14  semaines.  

 Ce   stage  a   été   effectué  au   sein  d’Avenir  Bureautique  à  Besançon.  Cette   entreprise,  

spécialisée  dans  les  systèmes  de  reproduction  et  de  communication,  m’a  accueilli  dans  le  cadre  d’un  projet  de  développement  d’une  nouvelle  GRC  (Gestion  de  la  Relation  Clients)  en  remplacement  d’une  ancienne  devenue  obsolète  et  inadéquate.  La  nouvelle  mouture  est   conçue   sur   le   logiciel   Vente   Partner   d’après   un   cahier   des   charges   où   je   devais  modifier  des  fenêtres  de  saisie  et  des  traitements  de  données  tout  en  relooking  de  tout  l’ensemble.    Mots  clés  

 FTP,  GRC,  langage  orienté  objet  C++,  requête  QBE,  requête  SQL,  SGBD  

 

Abstract    The   professional   degree   of   Computer   Science   proposed   by   the   Université   de  

Franche-­‐Comté  (Besançon,  France)  during  a  year  is  validated  through  an  apprenticeship  in  a  company  for  a  period  of  14  weeks.    

 This   apprenticeship   has   been   done   in   Avenir   Bureautique   in   Besançon.   This  

company   is   specialized   in   systems   of   reproduction   and   communication.   The   project  consisted  in  developing  a  new  CRM  (Customer  Relationship  Management)  to  replace  an  old   version   that   had   become   obsolete   and   inadequate.   The   new   version   is   conceived  based   on   the   software   Vente   Partner   following   a   scope   statement   in   which   I   had   to  modify   all   type-­‐in   windows   and   data   analysis   and   perform   a   relooking   of   all   the  software.    Key  words  

 CRM,  FTP,  Object-­‐oriented  language  C++,  QBE  request,  SQL  request,  DBMS