Vous êtes sur la page 1sur 22

Rapport de stage

Référent : Mr Nicolas HERVE, Responsable Informatique

1
SOMMAIRE

1) Présentation du Stade Rennais Football Club

1.1 Présentation et historique.

1.2 Infrastructure informatique.

2) Rôle du service informatique

2.1 L’assistance aux utilisateurs.

2.2 L’application Isybill et la CRM Web

2.3 Le contrôle d’accès.

3) Projets réalisés sur la période de stage

3.1 L’inventaire et gestion du parc informatique.

3.2 Exchange 2003.

3.3 Implémentation du wifi sur le site de l’enceinte sportive.

3.4 Mise en place d’un serveur de test de contrôle d’accès.

3.5 L’organisation de la finale de Coupe de France

3.6 Mise en situation pour RENNES-NANCY

4) Conclusions et aspirations

4.1 Bilan de la période de stage.

4.2 Perspectives d’embauche.

4.3 Conclusions et évaluation du maître de stage

2
1) Présentation du Stade Rennais Football Club

1.1 Présentation

Le Stade Rennais Football Club (SRFC), crée en 1901, ne connaît la stabilité au plus haut niveau que depuis
1994. Malgré les formidables épopées de 1965 et 1971, dates des finales de Coupe de France remportées par
le club, celui-ci ne parvient pas à rester dans le championnat élite français, et connaît par conséquents de
multiples ascensions et descentes du championnat de première division.

Ce n’est que depuis 2005 que le SRFC a pris une réelle dimension européenne, terminant régulièrement dans
les 5 premières places, synonyme de qualification européenne.

Le centre de formation du Stade rennais est très réputé. Fondé en 1977 mais réellement développé en 1987,
le centre a formé nombre de futurs grands joueurs (S.Wiltord, O.Dabo, M.Sylvestre ou plus récemment
Y.Gourcuff). En 2008, le centre est désigné meilleur centre de formation de France pour la 3e année
consécutive par la Direction technique nationale. Selon une étude menée par le Centre international d'étude
du sport et le Centre d'étude et de recherche sur le sport et l'Observation des territoires, le centre de
formation du Stade rennais occupe la 5e place des 98 clubs des cinq meilleurs championnats européens
(Allemagne, Angleterre, Espagne, France et Italie).

1.2 Infrastructure informatique

Le siège administratif du Stade Rennais est situé à la Piverdière à Rennes (ainsi que le centre d’entraînement
professionnel).

Les bureaux de l’exploitation du stade ainsi que le centre de formation se trouvent quant à eux sur le site
même de l’enceinte sportive, de même pour les billetteries.
Afin que les 2 sites puissent avoir accès au même réseau, un pont wifi composé de 4 antennes relais a été
mis en place, comme l’indique le schéma ci-dessous.

Architecture réseau

3
2) Rôle du service informatique au sein de l’entreprise

2.1 L’assistance aux utilisateurs

Avec une quarantaine d’utilisateurs quotidiens, l’assistance et le dépannage informatique occupent une place
importante dans l’organisation du service informatique.

C’est un domaine complètement aléatoire, où l’on peut passer d’une intervention dite basique (installations
hardware/software) à des situations plus complexes demandant à la fois des connaissances mais aussi un
sens de la logique (problèmes d’ouvertures de sessions sur le domaine, accès aux lecteurs réseau refusés,
imprimantes non accessibles, etc…).

C’est cette tâche qui me fut allouée en grande partie lors de mon arrivée à l’entreprise, puis tout au long de
l’année. C’est un excellent moyen de débuter car cela permet d’une part de se familiariser avec les employés
des différents services, et d’autre part d’apprendre soi même les rudiments du métier. La banalité et la
diversité des interventions n’en constituent pas moins une base de connaissance sérieuse, continuellement
enrichie au fur et à mesure du temps.

2.2 Application Isybill et CRM Web

Annexe 1 : Exemple de requêtes effectuées (page 14 et 15)

Isybill est l’application éditée par la Ligue de Football Professionnelle (LFP) permettant aux clubs de gérer
la vente de billets. Aujourd’hui, 4 logiciels de ce type sont référencés dans les clubs de football
professionnels.

Un utilitaire appelé WinGa (propres développements du SRFC) est une interface entre l’outil CRM et
l’application de billetterie isyBill qui permet l’enregistrement de toutes les transactions entre le SRFC et ses
abonnés. (historique des achats clients).

Depuis le milieu des années 90, les clubs de football professionnels disposaient d’un système de vente de
billets ( ‘TicketFoot’) qui ne répondait plus aux nouveaux besoins (vente par Internet, exploitation des fiches
clients, envoi de mails aux abonnés). De plus, le matériel était devenu obsolète et il était très difficile de
pouvoir se procurer des pièces en cas de panne.

Ce nouveau programme dénommé ‘Isybill’ a été installé à Lyon (site pilote) en 2003, puis à bordeaux (sept
2004) et Rennes (nov 2004). Toutes les données existantes dans ‘TicketFoot’ ont été importées dans
‘Isybill’ (plans du stade, tribunes, fiches abonnés, tarifs, etc.).

Voici quelques captures d’écran pour apprécier les fonctionnalités d’Isybill.


Information sur la place Information sur la tribune

4
Vue globale de la tribune

Attribution du tarif en fonction de la


catégorie (CE, -16 ans ;;;) et de la
tribune.,

L’interface WinGa est connectée via des web services aux applications de billetterie,
CRM et facturation. Un client se présente au guichet pour renouveler son abonnement
(il peut s’agir d’un nouvel abonné). L’application effectue une recherche du client
dans la base CRM en fonction des données nom et prénom, mais également grâce au
numéro de la puce RFID de sa carte d’abonné (cette dernière recherche garantie une
recherche sûre de la fiche). Le guichetier doit alors mettre à jour sa fiche puis l’ajouter
au panier de commande. S’il s’agit d’un nouveau client, à l’enregistrement de la fiche,
cette dernière est automatiquement créée dans les deux applicatifs et les identifiants
sont croisés (l’identifiant isybill est enregistré dans la fiche CRM et inversement). La
vente de la place d’abonnement a lieu dans Isybill et est associée à la fiche
précédemment créée ou mise à jour. Au retour dans l’application Winga, le
chargement du panier permet de récupérer la vente de l’enregistrer dans la CRM
(constituant ainsi un historique de vente sur plusieurs saisons). Le guichetier peut
ensuite imprimer la nouvelle carte d’abonné, l’imprimante lit le numéro de la puce et
l’envoie dans la billetterie (sur la fiche du client) et dans la CRM. Plus tard, le numéro

5
de puce sera envoyé au contrôle d’accès pour permettre l’entrée de l’abonné au
Stade, via les tourniquets. Une fiche d’abonnement se présente comme suit :

Le schéma ci-dessous permet de bien comprendre la manière dont les informations recueillies lors d’une
vente en billetterie propre au SRFC, sont ensuite redirigées via les Web-services et l’application Isybill dans
la CRM :

ORGANISATION SYSTEME D’INFORMATION


D’INFORMATION
Echanges données clients
Passerelles existantes
Réseaux externes = Passerelles à créer
Guichet
Identification inexistante Téléphone Passerelles à définir

SUPER U FRANCE
Réseau existant opérationnel
CONFORAMA TICKET NET Réseau existant / en évolution
BILLET
BOUTIQUE Réseau à créer

Plateforme web = outil de


vente et de ré
référencement ISYBILL
Ticketing
central
WEB
E-ticketing
Premium CONTRÔLE
Plateforme de D’ACCES
services Gesti CRM
o
écha n des s
SPORTFIVE nges ta
infos tuts cli en Stockage B to C
clien ts et
Vidéo ts
Encaissement Outil commercial
Premium

SAGE

Banque FACTURE
Rapprochement
COMPTA
Remise en
en banque
banque

Mardi 14 mars 2006 : Programme de développement

On trouve 2 types d’enregistrement :

- Lors des campagnes d’abonnements (Salon Jean Prouf ou boutique officielle), les informations de
vente recueillies sont automatiquement référencées dans la base CRM-SRFC (table histoachat)

- Tout au long de la saison, les informations recueillies lors des ventes Web (etickets) sont quant à elles
redirigées vers une base de données spécifique, la base e-ticket (table histoeticket).

6
Ceci permet bien évidemment d’enrichir le plus précisément possible la base de données afin de l’exploiter
ensuite.

Voici une copie écran de l’historique des ventes d’e-tickets :

2.3 Le contrôle d’accès

Annexe 1 : Plan du stade et correspondance portes/lecteurs (page 16)


Annexe 2 : Requête SQL sur le contrôle d’accès (page 17).

Le contrôle d’accès regroupe tous les moyens mis en œuvre pour accueillir un client porteur d’un titre
d’entrée valide. C’est par le biais de ce contrôle d’accès que le SRFC est un précurseur en France avec
l’acquisition en 2007 de tourniquets dotés de lecteurs de code barre et lecteurs RFID pouvant différencier un
titre valide d’un titre non valide, vérifier si le tarif du titre est en adéquation avec le client qui se présente au
contrôle (que ce soit un billet acheté en point de vente ou un ticket acheté sur le site internet, une carte
RFID ou un chéquier abonné : remise à l’abonné société de l’ensemble des titres de la saison en format
billet).

Les données de passage sont stockées dans la base CRM et permettent entre autre de connaître précisément
les heures d’arrivées des spectateurs, l’affluence réelle des matchs et d’analyser le nombre de sièges abonnés
libres en fonction des rencontres de ligue 1 :

7
70% des voies d’accès sont équipées de ce système.

Les objectifs du contrôle d’accès est de fluidifier l’accès aux entrées du stade et d’ainsi faciliter la tâche du
personnel « soir de match » et d’anéantir totalement les risques de fraudes (faux ticket, ticket déjà
validé,….) et notamment le « Print at Home », fraude consistant à imprimer plusieurs fois un e-ticket pour
tenter de le valider plusieurs fois.

Pour simplifier la présentation de la méthode du contrôle d’accès, on peut dire que ce système fonctionne
avec des web services qui récupère d’une part l’ensemble des n° de carte RFID et les codes barres des
chéquiers des abonnés, et d’autre part l’ensemble des codes barres des titres achetés dans le commerce
(Carrefour, Leclerc, Fnac, boutique, guichet…). Pour chaque titre passé au contrôle d’accès, le tourniquet
interroge le serveur pour connaître sa validité et contrôler sa tarification (si la lampe s’allume ‘Jaune’ le
client doit justifier son demi-tarif – de 16 ans, carte d’étudiant, d’invalidité…).
Utilisation sous forme de tableau Excel du résultat d’une requête SQL concernant la fréquentation réelle par rapport aux ventes.

Graphique permettant de visualiser le pourcentage d’abonnés (RFID et chéquiers) et d’e-ticketeurs ayant acheté un titre mais étant absent lors du match.

8
3) Projets réalisés au cours de la période de stage

3.1 L’inventaire et le suivi du parc informatique

Les applications servant à assurer le suivi de la gestion de parc sont des solutions libres : OCS Inventory et
GLPI. Le couplage de ces deux utilitaires permet le recensement de tous les ordinateurs du parc avec l’exact
rapport de toute leur configuration, y compris la liste des logiciels et programmes installés sur chacun
d’entre eux. On peut associer OCS à l’inventaire du parc, et GLPI à sa gestion. (Helpdesk, base de
connaissance, etc.).

Ces deux softwares en étaient juste au point de l’installation à mon arrivée et j’ai eu la charge du
référencement de tous les logiciels dans la base OCS, de l’élaboration de la base de connaissance de GLPI et
des diverses tâches nécessaire à la mise en place de ce genre d’application. (création de comptes,
synchronisation avec l’Active Directory du serveur contrôleur de domaine,….)

3.2 Migration de la messagerie : Exchange 2003

L’année 2009 a été également marquée par la migration totale de la messagerie vers la version d’Exchange
2003, ce qui a permis aux employés concernés de pouvoir consulter leurs mails professionnels hors du site
de l’entreprise.

Cette migration a bien sûr nécessité une stratégie de sécurité renforcée pour garantir la confidentialité des
mails transitant via Exchange.

La solution retenue en matière de sécurité du réseau est celle proposée par IP Diva, entreprise éditeur de
solutions de sécurité VPN SSL.

Le principe de sécurisation est garanti par une authentification effective de chaque utilisateur lors de sa
connexion au serveur de l’entreprise, et est compatible avec plusieurs serveurs de l’intranet (fichiers,
messagerie, applications, …).

9
La plateforme VPN SSL IPdiva Mediation rend possible cet accès distant indépendamment du lieu, des
infrastructures réseau et du type de terminal utilisé dès lors qu’une connexion vers Internet est disponible.
Grâce à sa topologie répartie, la plateforme VPN SSL d’IPdiva est très simple à déployer et très facile à
opérer. Par ailleurs, contrairement aux solutions alternatives de type VPN Réseau (IPsec ou MPLS), le
terminal distant n’est pas considéré comme un élément du réseau local. Il en résulte une sécurité supérieure
que ce soit en terme d’intrusion malveillante ou en terme de discrimination l’accès aux ressources internes
d’une organisation Différents modes d’accès sécurisé à un serveur de messagerie sont supportés à savoir:

• L’accès redirigé en mode SMTP, POP3/IMAP ou MAPI (Exchange 2003)


• L’accès webmail étendu tel que OWA (Outlook Web Access) ou iNotes pour les PC sous Windows.
• L’accès webmail simplifié tel que OMA pour les PDA sous Windows CE.

Dans le premier cas (accès redirigé), la solution IPdiva permet de simuler la présence locale des serveurs de
mail au travers d’agents de redirection des ports TCP associés ces applications ou de redirection RPC (rpc
over http). Dans les autres cas (accès de type webmail), la solution IPdiva de VPN SSL sécurise l’accès à
distance au portail webmail disponible pour l’application utilisée (Exchange, Notes…).

La solution IPdiva agit comme mandataire d’interface entre des serveurs d’une infrastructure interne
(Intranet) et des terminaux distants équipés de navigateurs web.

Grâce à des mécanismes performants de réécriture d’URL, à la volée, la majorité des sites web destinés à
être consultés en interne deviennent disponibles à l’extérieur d’une organisation au travers d’un simple
navigateur web.

Pour des serveurs Intranet complexes, tels que des serveurs intégrant des complexes (javascript, applet
Java), IPdiva propose l’activation d’un redirecteur HTML accessible à la demande lors de la sélection du
service.

Pour tous ces avantages, le service informatique a retenu cette solution, moins couteuse et très performante.

3.3 Mise en place du wifi au Stade de la route de Lorient

Annexe 4 : Infrastructure du réseau sans fil au Stade de la Route de Lorient (page 18)

Disposition des AP dans l’enceinte sportive

10
Les demandes de réseau sans fil au stade de la route de Lorient se faisant de plus en plus pressantes,
notamment avec les différents séminaires organisés dans les salons du stade mais aussi avec les besoins des
journalistes lors des rencontres sportives, il a été décidé de mettre en place le wifi. Après plusieurs rendez
vous de chantier avec les organismes concernés (France Telecom, électricien, etc.), le projet a pu débuter en
Mars 2009.

Pour résumer les travaux réalisés, il a fallu installer une nouvelle baie de brassage (taille 9U) afin de
pouvoir recevoir une nouvelle fibre optique. Ensuite, il a fallu disposer des Access Point aux endroits
stratégiques (en fonction des la portée des AP).

La mise en place du wifi s’est déroulée en 2 phases :

- Phase 1 : disposition des AP pour « arroser » les zones journalistes et photographes.


- Phase 2 : finalisation du projet avec le wifi disponible dans les salons VIP (juin 2009).

3.4 Mise en place d’un serveur de test

La mise en place d’un serveur de test était une obligation technique pour le SRFC qui cherchait à combler 2
lacunes de son système concernant le contrôle d’accès :

- Assurer une reprise d’activité rapide en cas de défaillances d’un serveur, permettant une
bascule automatique du système de billetterie et de contrôle d’accès.

11
- Disposer d’un environnement de test en réelles conditions de production, tout en n’impactant
pas les données actives. (notamment avec les mises à jour du logiciel de billetterie).

Le principe de virtualisation consiste à installer sur les serveurs une fine couche logicielle (hyperviseur)
permettant d’installer plusieurs systèmes d’exploitation (Unix, Linux, Windows) sur le même serveur
physique.

L’ensemble des périphériques peut donc être partagé entre plusieurs systèmes (contrairement à une
architecture classique) qui se partagent alors la mémoire, le(s) processeur(s) et le(s) disque(s).
Les systèmes d’exploitation, les applications installées sur les serveurs, ainsi que les données stockées
forment des fichiers regroupés en un répertoire.

Ce répertoire constitue un système complet qu’il est alors facile de transférer sur un autre serveur et de
sauvegarder. Ce répertoire constitue une image virtuelle qui s’administre et est en vue sue le réseau comme
un serveur classique.

Le logiciel DoubleTake assure la réplication des données des machines virtuelles (Isybill t Team Access)
vers les machines virtuelles situées sur le serveur de backup. Cette réplication est automatique et fonctionne
en permanence, grâce à l’insertion d’un driver entre le système d’exploitation et le sous système disque,
permettant ensuite la capture des modifications et leur envoi ensuite vers le serveur secondaire.

Voici le schéma simplifié de cette plateforme :

Dans cette configuration, il n’existe pas de système de stockage disque partagé : chaque serveur dispose de
ses propres disques et systèmes d’exploitation, et une réplication des données est organisée entre chaque
serveur.

12
En cas de défaillance de l’une ou plusieurs des machines virtuelles, ou du serveur physique, les machines
virtuelles du serveur de backup, ou bien le serveur complet, reprennent l’identité réseau du serveur principal
défaillant et continuent la production. C’est la procédure de failover.

Lors du retour en production du serveur principal, une procédure de failback est appliquée afin de remettre
le système en production.

3.5 L’organisation de la finale de Coupe de France

L’événement sportif de l’année a bien entendu été la participation du club à la finale de la Coupe de France.
Vivre une telle aventure de l’intérieur a été une véritable découverte professionnelle. En effet, la surcharge
de travail provoquée par l’organisation mise en place m’a permis de tester ma polyvalence quant à des
fonctions que jamais je n’avais occupées auparavant.

La mise en vente des billets pour les supporters rennais a nécessité une organisation exceptionnelle. C’est
ainsi que j’ai eu la tâche de participer au centre d’appels mis à disposition afin de répondre à tout demande
d’information de la part des particuliers. Cette journée fut pour moi l’occasion de tester ma capacité à
éclairer au mieux mon interlocuteur, en restant bien évidemment courtois, même avec les personnes les plus
véhémentes. L’autre difficulté a bien sûr été de gérer plusieurs appels simultanés sans céder à la panique du
nombre d’appels.

J’ai également eu la chance de pouvoir participer à la vente en elle-même des billets. J’ai pu ainsi découvrir
les principales compétences qu’un(e) guichetier(e) doit posséder, à savoir une concentration permanente
quant aux calculs pour les règlements, une réactivité certaine pour ne pas perdre de temps lors d’une vente,
et surtout une organisation huilée afin de garder son poste de vente le plus cohérent possible.
En conclusion, mes journées passées au centre d’appels et aux guichets m’ont enthousiasmé et m’ont fait
découvrir un aspect nouveau de l’entreprise.

3.6 Mise en situation pour RENNES-NANCY

Après avoir longuement observé la procédure du contrôle d’accès en soir de match, j’ai eu l’immense
opportunité de gérer seul la préparation d’une rencontre à domicile.

L’import automatique des ventes web débute 5 jours avant le début du match, ce qui permet de ne pas
saturer le serveur en important tout le jour du match.

La première vérification à effectuer est la présence des tourniquets sur le réseau. Ainsi, il faut s’assurer que
toutes les voies d’accès sont opérationnelles. Il faut ensuite envoyer à chaque lecteur un fichier texte
contenant « le code barre intelligent ». Ce système permet aux tourniquets de s’autogérer en cas de panne
réseau (panne électrique, serveur HS, …) car ils sont capables avec ce fichier de reconnaître un titre valide
d’un titre non-valide sans aller interroger le serveur.

La troisième étape consiste à interrompre momentanément l’import des ventes pour aller vérifier chaque
lecteur en le testant avec des titres valides et non valides pour voir si la machine réagit selon le protocole
voulu.
Il suffit ensuite de relancer l’import automatique toutes les secondes afin de permettre à un client de pénétrer
dans l’enceinte sportive aussitôt son billet acheté.

13
Une fois la procédure du contrôle d’accès validée, il faut se préparer à toute éventualité de panne : cela peut
être matériel (poste de guichet défectueux, problème de bras sur les tourniquets,….), logicielle ou réseau,
l’objectif étant bien entendu d’assurer le bon fonctionnement informatique du site jusqu’au coup d’envoi.

4) Conclusions et aspirations

4.1 Bilan personnel de la période de stage

Je me réjouis d’avoir effectué mon stage au Stade Rennais. En effet, mis à part d’avoir pu entrer dans le club
de foot dont je suis supporteur depuis tout petit et d’avoir côtoyé les joueurs professionnels ainsi que les
anciennes gloires restées au club, la diversité des tâches effectués et les connaissances acquises sont
supérieures à mes attentes de début d’année.

L’extrême amabilité des employés m’a considérablement aidé pour favoriser mon intégration au sein de
l’entreprise. J’ai également eu la chance de rencontrer un maître de stage absolument compétent et le plus
disponible qu’il pouvait l’être. Sa pédagogie m’a permis d’être autonome assez rapidement, au point
d’assurer seul le contrôle d’accès lors du match à domicile du 14/02/2009, et aussi d’être compétent lors des
deux semaines de congés qu’il a prises me laissant seul au service informatique au sein de l’entreprise.

Mon seul regret est de n’avoir pas eu suffisamment de temps pour pousser encore plus loin mes
connaissances et mes acquis en SQL, et aussi de ne pas avoir pu suivre de bout en bout pour cause de cours
à l’Aftec les mises en place d’Exchange 2003 et du serveur de test de contrôle d’accès. En conclusion, je
remercie le plus sincèrement Mr Nicolas Hervé pour son enseignement et j’espère vraiment pouvoir
continuer à travailler avec lui.

14
4.2 Perspective d’embauche

En vue de la conjecture actuelle, et malgré le fait que le service informatique ne se compose que d’une seule
personne, il n’est pas certain que ma période de stage se termine par une offre d’emploi au SRFC, même si
la situation inverse n’est pas exclue non plus.

En effet, une éventuelle proposition d’embauche dépend en grande partie des résultats sportifs de l’équipe
professionnelle : une place en coupe européenne aurait pu être synonyme d’une augmentation du nombre de
matchs et donc d’un besoin supplémentaire au niveau du contrôle d’accès, (engendrant également une
charge de travail supplémentaire pour les services administratifs et commerciaux, de plus en plus
demandeurs et surtout tributaires du service informatique). Si les perspectives d’embauche sont minimes au
SRFC, le réseau de prestataires dont l’entreprise dispose n’en est pas moins conséquent et j’ai bon espoir
d’obtenir une réponse positive de la part de l’un d’entre eux.

4.3 Conclusions et évaluation du maître de stage

Dès le début, Morgan a semblé très à l’aise avec les collaborateurs du SRFC. Son adaptation à de ce fait été
très facile. Ceci est un point important car le SI intervient auprès de l’ensemble des services et des salariés
de notre société.

Je tiens à remercier vivement Morgan pour la qualité du travail fourni, le sens du service dont il a fait
preuve, sa disponibilité (du fait de quelques astreintes spécifiques à notre activité). Il a été force de
proposition sur le dossier de la mise en place de l’outil de gestion du parc informatique. Toujours
demandeur et motivé, il a su également être suffisamment autonome pour mener à bien les missions qui lui
ont été confiées.

C’est donc tout naturellement que je lui confierai la responsabilité du contrôle d’accès et la maintenance
informatique, sur les deux premiers matchs de la saison, à savoir le match amical Rennes / Nantes et le
premier match de L1, Rennes / Boulogne sur mer.

15
16
ANNEXES

Annexe 1

Exemples de requêtes SQL effectuées au sein de l’entreprise, classées par complexité

Sociétés n’ayant pas d’attachés commerciaux


SELECT Company.Comp_CompanyId, Company.Comp_Name, Address.Addr_Address1, Address.Addr_City, Address.Addr_PostCode,
Company.Comp_PrimaryAddressId, Address.Addr_AddressId, Company.Comp_PrimaryPersonId, Person.Pers_LastName,
Person.Pers_FirstName,
Company.comp_representant
FROM Company INNER JOIN
Address ON Company.Comp_PrimaryAddressId = Address.Addr_AddressId INNER JOIN
Person ON Company.Comp_PrimaryPersonId = Person.Pers_PersonId
WHERE (Company.comp_representant IS NULL)

17
Sociétés dont l’historique commercial est mal voire pas renseignée au niveau de la saison
SELECT HistoriqueGescom.hg_dodate, HistoriqueGescom.hg_dopiece, HistoriqueGescom.hg_ctnum, sum
(HistoriqueGescom.hg_dlmonatntttc),comp_name
, Address.Addr_Address1, Address.Addr_PostCode, Address.Addr_City, HistoriqueGescom.hg_saison
FROM HistoriqueGescom INNER JOIN
Company ON HistoriqueGescom.hg_ctnum = Company.comp_codecomptable LEFT OUTER JOIN
Address ON Company.Comp_PrimaryAddressId = Address.Addr_AddressId
WHERE (HistoriqueGescom.hg_saison NOT LIKE 'Saison 2008-2009%' OR
HistoriqueGescom.hg_saison IS NULL) AND (HistoriqueGescom.hg_dodate > '01/06/2008')
GROUP BY HistoriqueGescom.hg_dodate, HistoriqueGescom.hg_dopiece, HistoriqueGescom.hg_ctnum,
Company.Comp_Name, Address.Addr_Address1, Address.Addr_PostCode, Address.Addr_City, HistoriqueGescom.hg_saison
ORDER BY HistoriqueGescom.hg_saison

Chiffre d’affaires réalisé sur les saisons 2007-2008 et 2008-2009 par client et par types
(hors entreprises)
SELECT Company.Comp_Name AS Entreprise, Company.comp_Nature AS Nature, Company.comp_representant AS ATC, SUM(CASE
WHEN (hg_arref)
LIKE '45BCH%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS
Montant_Billet_L1_08_09,
SUM(CASE WHEN (hg_arref) LIKE '45BLI%' AND hg_saison = 'Saison 2008-2009' THEN
(HistoriqueGescom.hg_dlmontantht) ELSE 0 END)
AS Montant_Billet_CDF_08_09, SUM(CASE WHEN (hg_arref) LIKE '45BFR%' AND
hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Billet_CDL_08_09,
SUM(CASE WHEN (hg_arref)
LIKE '45BU%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS
Montant_Billet_UEFA_08_09,
SUM(CASE WHEN (hg_arref) LIKE '45pgn%' AND hg_saison = 'Saison 2008-2009' THEN
(HistoriqueGescom.hg_dlmontantht) ELSE 0 END)
AS Montant_Billet_GN_08_09, SUM(CASE WHEN (hg_arref) LIKE '1%' AND hg_saison = 'Saison 2008-2009' THEN
(HistoriqueGescom.hg_dlmontantht)
ELSE 0 END) AS Montant_VIP_08_09, SUM(CASE WHEN (hg_arref) LIKE '2%' AND
hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Pub_08_09,
SUM(CASE WHEN (hg_arref)
LIKE '45BCH%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BLI%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BFR%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BU%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +

SUM(CASE WHEN (hg_arref)


LIKE '45pgn%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '1%' AND hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) + SUM(CASE
WHEN (hg_arref) LIKE '2%' AND
hg_saison = 'Saison 2008-2009' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Total_08_09,
SUM(CASE WHEN (hg_arref)
LIKE '45BCH%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS
Montant_Billet_L1_07_08,
SUM(CASE WHEN (hg_arref) LIKE '45BLI%' AND hg_saison = 'Saison 2007-2008' THEN
(HistoriqueGescom.hg_dlmontantht) ELSE 0 END)
AS Montant_Billet_CDF_07_08, SUM(CASE WHEN (hg_arref) LIKE '45BFR%' AND
hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Billet_CDL_07_08,
SUM(CASE WHEN (hg_arref)
LIKE '45BU%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS
Montant_Billet_UEFA_07_08,
SUM(CASE WHEN (hg_arref) LIKE '45pgn%' AND hg_saison = 'Saison 2007-2008' THEN
(HistoriqueGescom.hg_dlmontantht) ELSE 0 END)
AS Montant_Billet_GN_07_08, SUM(CASE WHEN (hg_arref) LIKE '1%' AND hg_saison = 'Saison 2007-2008' THEN
(HistoriqueGescom.hg_dlmontantht)
ELSE 0 END) AS Montant_VIP_07_08, SUM(CASE WHEN (hg_arref) LIKE '2%' AND
hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Pub_07_08,
SUM(CASE WHEN (hg_arref)
LIKE '45BCH%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BLI%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BFR%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '45BU%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) + SUM(CASE

18
WHEN (hg_arref)
LIKE '45pgn%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) +
SUM(CASE WHEN (hg_arref)
LIKE '1%' AND hg_saison = 'Saison 2007-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) + SUM(CASE
WHEN (hg_arref) LIKE '2%' AND
hg_saison = 'Saison 2008-2008' THEN (HistoriqueGescom.hg_dlmontantht) ELSE 0 END) AS Montant_Total_07_08
FROM Company INNER JOIN
HistoriqueGescom ON Company.comp_codecomptable = HistoriqueGescom.hg_ctnum
WHERE (Company.comp_Nature <> 'Entreprises') AND (Company.Comp_Deleted IS NULL) AND (HistoriqueGescom.hg_saison IS
NOT NULL) AND
(HistoriqueGescom.hg_saison = 'Saison 2008-2009' OR
HistoriqueGescom.hg_saison = 'Saison 2007-2008') AND (HistoriqueGescom.HG_Deleted IS NULL)
GROUP BY Company.Comp_Name, Company.comp_Nature, Company.comp_representant

Annexe 2

Plan du stade et correspondance portes/lecteurs

19
Annexe 3

Requête permettant de contrôler les écarts entre l’affluence estimée et l’affluence réelle.

20
SELECT ca_Manifestation, ca_support, SUM(CASE WHEN (ca_porteattendue) = 'Porte 1' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 1' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) ,
ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 1' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN
(ca_porteattendue)
= 'Porte 1' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 1' THEN 1 ELSE 0 END) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 3' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 3' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) , ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 3' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 3' THEN 1 ELSE 0.00001 END), 0) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 3' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 4' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 4' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) ,
ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 4' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN
(ca_porteattendue)
= 'Porte 4' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 4' THEN 1 ELSE 0 END) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 6' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 6' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) , ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 6' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 6' THEN 1 ELSE 0.00001 END), 0) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 6' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 7' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 7' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) ,
ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 7' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN
(ca_porteattendue)
= 'Porte 7' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 7' THEN 1 ELSE 0 END) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 11' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 11' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) , ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 11' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 11' THEN 1 ELSE 0.00001 END), 0) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 11' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 12' AND
(ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 12' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END)
, ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 12' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END)
* 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 12' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 12' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 13' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END)
, SUM(CASE WHEN (ca_porteattendue) = 'Porte 13' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) ,
ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 13' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN
(ca_porteattendue)
= 'Porte 13' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 13' THEN 1 ELSE 0 END) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 16' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 16' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) , ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 16' AND (ca_passage)
= 'Y' THEN 1 ELSE 0 END) * 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 16' THEN 1 ELSE 0.00001 END), 0) ,
SUM(CASE WHEN (ca_porteattendue) = 'Porte 16' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 17' AND
(ca_passage) = 'Y' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) = 'Porte 17' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END)
, ROUND(SUM(CASE WHEN (ca_porteattendue) = 'Porte 17' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END)
* 100.0 / SUM(CASE WHEN (ca_porteattendue) = 'Porte 17' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue)
= 'Porte 17' THEN 1 ELSE 0 END) , SUM(CASE WHEN (ca_porteattendue) <> 'Porte 145' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END)
, SUM(CASE WHEN (ca_porteattendue) <> 'Porte 145' AND (ca_passage) <> 'Y' THEN 1 ELSE 0 END) ,
ROUND(SUM(CASE WHEN (ca_porteattendue) <> 'Porte 145' AND (ca_passage) = 'Y' THEN 1 ELSE 0 END)
* 100.0 / SUM(CASE WHEN (ca_porteattendue) <> 'Porte 145' THEN 1 ELSE 0.00001 END), 0) , SUM(CASE WHEN (ca_porteattendue)
<> 'Porte 145' THEN 1 ELSE 0 END)
FROM ControleAcces
WHERE (CA_Deleted IS NULL) AND (ca_saison = 'Saison 2008-2009') AND (ca_spectacle = 'LIGUE 1') AND (ca_Pool NOT LIKE '%loges%') AND
(ca_Pool NOT LIKE '%Breizh%') AND (ca_Pool NOT LIKE '%visiteurs%') AND (ca_Pool NOT LIKE '%prouff%') AND (ca_Pool NOT LIKE
'%roazhon%')
GROUP BY ca_Manifestation, ca_support
ORDER BY ca_Manifestation, ca_support

Annexe 4

21
Infrastructure du réseau sans fil au Stade de la Route de Lorient

22

Vous aimerez peut-être aussi