Groupe 1 Cyprien DEBU Ismail KAMALI Gaëtan NOUCHET Paul PETIT Antoine SOUQUES Thibaut STREMPLEWSKI 1

Sommaire Contexte du projet But du projet Portée du projet Processus Modèle de données simplifié Architecture logicielle Estimation des flux Architecture matérielle 2

Contexte du projet (MaintUp) MaintUp, société de gestion d’ascenseurs, veut améliorer son service vis-à-vis de ses clients et augmenter sa productivité Trois types de clients : Particuliers Ascensoristes Grands comptes Afin d’investir dans les nouvelles technologies de l’information, MaintUp lance un appel d’offre fin

But du projet Dresser une architecture de SI qui permette l’automatisation, l’optimisation et la traçabilité de : L’affectation des actes de maintenance aux techniciens La planification des tournées des techniciens La récupération et du traitement des comptes-rendus d’intervention Une architecture optimale au niveau de : Fiabilité Taux de disponibilité de 99%, 24h/24, 7j/7 Coût Juste prix Éviter la sur-qualité Techniciens plus efficaces et plus productifs Délai D’avertissement de panne De réparation Qualité Service Ergonomie des IHM Bonne communication client/sous-traitant 4

Portée du projet Utilisation de solutions de mobilité Tablettes Internet 3G Utilisation d’algorithmes d’optimisation mathématique Extensibilité du système (Région  France  Europe  Monde) Capacité de gérer de grosses bases de données Garder la possibilité d’une éventuelle expansion de la société Interopérabilité avec le système existant Internet ADSL ERP MaintUp Call center 5

6 Fournissent les demandes Demandes mensuelles d’intervention Établit le plan de maintenance Catalogue d’ascenseurs Infos techniciens Plan de maintenance préventive Construit les plannings Modifie les plannings Planning d’intervention pour chaque technicien Font la maintenance et les comptes-rendus Reçoit les appels d’urgence Demandes d’intervention Comptes-rendus Reçoivent des demandes de dépannage Demandes d’intervention urgent semi-urgent Analyse les comptes-rendus Met à jour le statut de l’ascenseur Prévient les utilisateurs Métriques contractuelles Tableaux de bord dépannage Publie les métriques Analysent les métriques Peuvent demander des compensations Techniciens Call Center Ascensoristes Solution logicielle Grands comptes/ particuliers Métriques contractuelles Analysent les métriques Peuvent demander des compensations Process

Modèle de données simplifié 7

Architecture logique 8

« Parc Français : ascenseurs accessibles aux personnes pannes par an au total en France 70% des pannes sont traitées dans la demi-journée 30% des pannes nécessitent de quelques jours à plusieurs semaines personnes bloquées dans les ascenseurs chaque année (dont 2/3 en région parisienne) » Fédération des Ascenseurs Hypothèse : Seulement 11% des appels sont urgents :  ~90% des appels doivent être passés de 8h à 20h ( appels)  Soit en moyenne : 41 appels/heure durant la journée. Une panne entraîne un changement de planning pour une zone de 5 techniciens : Soit en moyenne 2500 changements durant la journée. Cas : Changement de planning

Flux : Employés - MaintUp 10 Hypothèses : Techniciens : Un planning fait environ 50ko, 2000 plannings journaliers changements Les rapports d’intervention font 20 à 30ko, un technicien réalise 5 à 6 interventions par jour Cas d’une application web : 100ko à 200ko (à chaque intervention et consultation du planning pour le chargement de l’interface etc …) Direction : 1-2 personnes par zone ; 5-10 connections aux statistiques (300 ko pages web incluses) EmetteurRécepteurDonnéesPoids unitairePoids journalierSupportProtocole MaintUp TechniciensPlanning50ko4500 * 50 = 225 MoInternet + 3G https (appli web) TechniciensMaintUpRapport30ko2000*6*30 = 36 MoInternet + 3G https (appli web) MaintUpDirectionStatistiques300 ko400*10*300 ko = 1.14 Go Internethttps

Flux : Clients - MaintUp 11 Hypothèses : ascenseurs : ~10 000clients particulier (1.5 ascenseurs en moyenne) ~ 20 Ascensoristes ( ascenseurs ) ~ 2000 Grands comptes (+20 ascenseurs) Ascensoristes : au moins 60 connections par jour sur l’appli web (~200ko) Grands comptes : 1 PDF + Excel par mois a date fixe  un pic de 2000 mails une fois par mois Clients : 1 lettre par an à terme du contrat ( +25 lettres par jour ) EmetteurRécepteurDonnéesPoids unitaire Poids journalierSupportProtocole MaintUp AscensoristesStatistiques Maintenance 200 ko60*20 * 200ko = 234 Mo Internethttps (appli web) MaintUpGrand Comptes PDF + Excel50+50ko2000*100 ko= 195 Mo InternetSMTP (mail)

Dimensionnement BDD Rapport : 50ko * 2000 techniciens * 6 interventions * 365j * 10ans (cf. flux) = 2.04 To Planning (1 définitif par jour) : 30ko * 2000 techniciens * 365j * 10 ans = 209 Go Planning des ascensoristes : 500ko * 20 ascensoristes * 12 mois * 10 ans = 1.2 Go Données ascenseurs : 100ko * ascenseur = 10 Go 12

Architecture matérielle Infrastructure de type Cloud privé chez un hébergeur (OVH) Machines Une brique de base (8 cœurs 2GHz, 16 Go RAM) équivaut à 3-4 machines  3 briques réservées au calcul (12 MV indépendantes) et 1 brique pour le reste Les autres composants tournent dans des serveurs d’application sur différentes MV Bande passante de 30 To/mois incluse 1 SAN de 2.4 To (sauvegarde à H-1 incluse et 100% de disponibilité par contrat) Mobile Tablette « bas de gamme » avec 3G : 100 € Période d'amortissement : 4 ans Quantité : 2000 Abonnement 3G Réduction pour achat en gros : forfait à 10 €/mois 13

Architecture matérielle MatérielCoût Briques de bases920€/mois 2000 tablettes 3G amorties sur 4 ans4200€/mois Abonnement 3G20 000€/mois Bande passanteincluse Stockage479 €/mois TOTAL25 600€/mois 14

Environnement Poste clientWindows, Mac et IE 6+, Firefox 3+, Safari 3+ HyperviseurVmware OSLinux (debian) Serveur HTTPTomcat Serveur d’applicationJboss SGBDPostgreSQL (potentiellement pgpool) TablettesAndroïd/Linux Serveur SMTP/MQPostfix + Dovecot 15