QOS optimization project using 6 Sigma method

1. Projet QOS : Bigger Data
Mastère Spécialisé Cloud Computing et SaaS, 2014/2015
Benoît Foussier
Eric Guillard
Sébastien Kieger
Clément Marche
1/26

2. Table des matières
1. Define
Présentation de Datatweet
Présentation du SI
Les acteurs
Les acteurs : OVH
Les acteurs : GNIP
Méthodologie
Critères clés de qualité
Analyse SWOT
Analyse des processus clés
Objectifs identifiés
2. Mesure
KPI de mesure identifiés
3. Analyze
Problèmes identifiés
Analyse des causes profondes
Choix de l’axe à traiter
Diagramme des causes profondes
Fiches labels
4. Improve
5. Control
Les contrôles
Les outils de pilotage
Tableau de Bord
Backlog
Sondage
Réunion
Conclusion
Annexes
Remerciements
2/26

3. 1. Define
Présentation de Datatweet
Datatweet est une start­up fondée en 2011 par 3 ingénieurs avec comme idée de base de se servir des
tweets pour suivre des tendances et analyser la e­reputation d’entreprises. Concrètement ils proposent une
solution SaaS basée sur des technologies liées au traitement massif de données, qui permet aux clients
d’observer les flux de conversations Twitter en temps réel et de les analyser pour cibler les origines, les
influenceurs et ainsi adapter leur communication de manière optimale.
Un des principaux usages de la solution Dataweet réside dans la détection anticipée de crises (affaire « La
parisienne », ou l’arrivée de Netflix en France par exemple) ainsi que la gestion de leurs résolution.
source : Blog datatweet
Âgée de 3 ans, Datatweet possède en 2014 une vingtaine de clients, et arrive à un point critique de son
évolution : la plateforme SaaS est fonctionnelle et stabilisée, l’outil de production et d’exploitation doit
maintenant évoluer pour s’industrialiser et permettre à Datatweet d’aborder l’avenir sereinement et de
manière pérenne. Ainsi elle pourra se concentrer sur son cœur de métier : l’évolution des fonctionnalités de
sa plateforme et la vente de cette solution à de nouveaux clients.
Consciente de cela, Datatweet souhaite faire évoluer son système d’information en utilisant, si besoin et
malgré des réticences évidentes, la puissance du cloud et les outils SaaS.
3/26

4. Présentation du SI
Actuellement on peut distinguer deux parties dans le SI :
● Le SI « core business » : qui permet de développer, de maintenir et de proposer aux clients la
plateforme SaaS de e­reputation
● Le SI « fonctions transverses » : qui regroupe les outils informatiques dédiés aux fonctions
transverses de la société (RH, CRM, Paie…)
Les acteurs
Le SI « core business » est un SI hébergé, basé sur une architecture de type “offre serveurs dédiés” avec
un minimum de services (gestion uniquement physique des machines). Cette prestation est contractualisée
avec OVH.
Le métier de Datatweet est basé sur l’analyse des flux de tweets, ils sont sa matière première. La
disponibilité de ces derniers est donc critique. Ces tweets sont disponibles via flux fourni par un prestataire
(GNIP, société appartenant à Twitter), qui vend l’accès aux flux de tweets. La contractualisation avec ce
prestataire est stratégique pour Datatweet : en effet d’une part cela constitue la majeur partie de ses
dépenses récurrentes, et d’autre part la disponibilité et l’exhaustivité des tweets est la base du modèle de
Datatweet.
Enfin, les clients finaux, qui accèdent directement aux SI de Datatweet en se connectant sur la plateforme
SaaS, sont également des acteurs important. En effet il est impératif qu’ils accèdent à un site performant qui
évolue régulièrement et où les problèmes sont résolus avec le minimum de délais. Ils contractualisent avec
4/26

5. Datatweet via un abonnement de type SaaS qui leur donne accès à la plateforme et à un certain volume de
tweets à analyser.
Les acteurs : OVH
OVH, créé en 1999, est un hébergeur français de sites web. Il propose des serveurs dédiés, des serveurs
privés, de l'hébergement mutualisé, du housing (ou colocation), des services de Cloud computing, de la
fourniture d'accès Internet par lignes ADSL, VDSL ainsi que SDSL, l'enregistrement de noms de domaine,
ainsi que de la téléphonie sur IP. Avec environ 180 000 serveurs en octobre 2014, OVH dispose de l'un des
plus grands parcs de serveurs au monde.
De plus, OVH a déployé son propre réseau de fibre optique, géré avec des équipements DWDM, à travers
le monde (Europe, Amérique et Asie). L'hébergeur avance une capacité totale de 3 Tbps.
(Cf. annexe 4)
Le réseau OVH Europe. 3000 Gbps de capacité vers l'Internet. (ovh)
Les acteurs : GNIP
GNIP est une société américaine d’agrégation et d’analyse des données issues des réseaux sociaux, parmi
lesquels Twitter, qui l’a rachetée en 2014. GNIP est une des rares sociétés possédant l’accès à la totalité du
flux Twitter.
La société Datatweet possède un contrat avec GNIP pour mise à disposition des données Twitter. Le flux de
données entre GNIP et Datatweet est un stream http (Comet).
Ce contrat confère un accès exhaustif aux tweets en temps réel, ce qui permet à Datatweet de garantir
l’exhaustivité des tweets et la quasi instantanéité de l’analyse des données.
Il est important de souligner que GNIP est le fournisseur exclusif de données de Datatweet. Ce dernier est
par conséquent très dépendant du flux de données fourni par GNIP.
(Cf. annexe 3)
5/26

6. Méthodologie
Le projet sera réalisé en se basant sur la méthode DMAIC :
En effet, cette méthodologie est adaptée au contexte : Datatweet est une start­up ayant 3 ans d’existence,
avec le besoin de consolider (voire industrialiser) ses processus, ses outils, le tout avec une qualité de
service améliorée afin de pouvoir proposer un service performant à ses clients, maintenant ou dans les
années à venir.
Pour cela, nous analyserons tout d’abord le contexte de Datatweet, ainsi que ses priorités (métier,
techniques, fonctionnelles) pour déterminer quels sont les enjeux de leur activité.
En fonction de ces enjeux, nous mettrons en place des indicateurs qualitatifs et quantitatifs qui nous
permettront de mesurer la qualité de service actuelle (ainsi que la qualité de service perçue) au sein de la
société. Cette étude nous permettra de mettre en lumière les points faibles de l’activité en terme de QoS,
pour comprendre ensuite les causes profondes de ces problèmes.
Puis nous proposerons des points précis à mettre en place ou à faire évoluer pour améliorer la qualité de
service ­ ces points nous permettront d'identifier des solutions du marché qui pourront supporter cette
amélioration.
Enfin nous nous assurerons de la bonne implémentation de cette solution en décrivant les points à contrôler
pour assurer une constante amélioration de la qualité de service.
Critères clés de qualité
Suite à nos entretiens, trois critères ressortent comme majeurs et critiques pour l'activité de la société :
● Performance : La plateforme de Datatweet traite des requêtes liées parfois à plusieurs millions de
tweets. Chaque tweet porte les informations de son créateur, son contenu, et son éventuel lien vers
un site web. Pour garantir une utilisation fluide et efficace de la plateforme, Datatweet doit assurer
des performances optimales. C’est une problématique au coeur de leur métier.
L’exigence se mesure ainsi : disponibilité des tweets 1 minute après leur parution, et traitement des
requêtes client en 4 secondes.
● Maîtrise : Elle se décline en deux sous­critères :
○ Tout d’abord la gestion de l’infrastructure pour garantir une intégration optimale avec le
logiciel et ainsi obtenir les meilleures performances possibles.
○ Ensuite la nature de l’activité de Datatweet l’oblige à maîtriser complètement ses données.
Si les flux Twitter sont publics, l’identité de ses clients et la nature des requêtes qu’ils
effectuent sur la plateforme sont confidentielles. Ainsi la maîtrise des données est garante
de la confidentialité.
● Sécurité : L’actualité nous montre que la sécurité reste la clef de voûte d’un SI industriel. Datatweet
y apporte une attention particulière. Les exigences pour Datatwet portent sur :
○ La disponibilité : hors période de maintenance planifiée la nuit (heure française), Datatweet
garantit une disponibilité de 99,99% pour sa plateforme. En cas d’indisponibilité partielle,
l’accessibilité àla plateforme Datatweet proposée à ses clients reste prioritaire par rapport
6/26

7. au flux GNIP. Le but étant de privilégier les requêtes sur les tweets déjà “en cache” et ainsi
de permettre aux clients de continuer à travailler;
○ L'intégrité : Datatweet garantit sur sa plateforme l'exhaustivité des tweets publiés sur
Twitter via son contrat avec GNIP ;
○ La confidentialité des données des Clients de Datatweet.
Analyse SWOT
Positif
(pour atteindre l’objectif)
Négatif
(pour atteindre l’objectif)
Facteurs Internes
“(Organisationnel)
­ Plateforme performante
­ Réactivité face aux bugs et
évolutions
­ Fonctionnement faisant une
utilisation forte de l’agilité
­ Architecture maîtrisée
­ Pas de processus définis
­ Une maintenance manuelle qui
prend du temps
­ Une expertise peu documentée
­ Manque de temps/de
ressources
­ Réticence au Cloud
­ Peu/pas d’outils de support
Facteurs Externes ­ Le besoin de connaissances
sur les réseaux sociaux se
développe (= nouveaux clients
potentiels)
­ Les outils Cloud arrivant à
maturité, ils peuvent répondre
au besoin d’élasticité, de
performance et de maîtrise
­ Processus et infrastructure
insuffisants face à
l’augmentation du nombre de
clients
­ Fournisseur exclusif de donnée
: risque
Il ressort de cette matrice les éléments suivants :
● Besoin d’industrialisation des techniques et des processus ;
● Besoin d’outils de support ;
● Besoin d’une infrastructure évolutive (“scalable”) pour répondre aux demandes croissantes de
nouveaux clients et pour permettre des évolutions fonctionnelles.
7/26

8. Analyse des processus clés
Compte tenu de la taille (start­up de 10 personnes) et de la structure de la société, nous avons identifié trois
processus clés : la gestion des demandes, la gestion de la maintenance, et les mises en production.
Les déploiements des nouvelles versions de la plateformese font avec l’aval du directeur technique, d’abord
sur l’environnement de test, puis sur l’environnement de production.
Ce processus ITIL peut encore être amélioré en incluant la gestion des changements et des configurations.
Voici des exemples d’évolutions:
● intégrer des collaborateurs Datatweet métiers dans des comités consultatifs des changements
(CAB) qui pourront faire des recommandations sur le contenu des développements et leur
calendrier de déploiement;
● intégrer les nouvelles versions logicielles et les modifications sur le matériel dans une CMDB
(Configuration Management Database) pour aider à contrôler ces éléments tout au long de leur
durée de vie.
8/26

9.
Lorsqu’un client formule une demande, celle­ci est gérée par les équipes IT de Datatweet au moyen d’un
fichier Excel. La gestion pourrait être améliorée avec un logiciel de ticketing ouvert au client.
Datatweet dispose de la solution Pingdom, un logiciel de supervision très complet et très performant.
Cependant, il n’y a pas de processus de gestion des incidents chez les équipes IT au sens ITIL du terme.
C’est un axe qui devra être amélioré.
9/26

10. Objectifs identifiés
Actuellement, le SI "core business" est hébergé et le SI "fonctions transverses" se limite à une gestion sur
tableur.
Le choix de ces solutions repose sur des décisions et des contraintes, pensées et définies pour une start­up
au démarrage de son activité. Arrivée dans une phase de développement, Datatweet doit initier une
réflexion autour des ces aspects.
L'objectif premier de ce projet est d'optimiser la partie "core­business" de l'activité de la société, ainsi que de
lui donner une architecture SI pérenne qui lui permettra de faire face à sa croissance importante. Il inclue le
support de sa plateforme SaaS ainsi que le hub d’échange entre les données Twitter (GNIP) et les requêtes
des clients. C’est un aspect critique pour la société car de lui dépendent la performance, la sécurité des
données ainsi que l’exhaustivité des données traitées.
L'objectif secondaire est de créer un SI "fonctions transverses” qui permettra de supporter l'activité sur le
long terme. Aujourd’hui basé sur des processus et des outils basiques, et n’ayant pas été le fruit d’une étude
poussée des besoins, il est à repenser et à créer. Si ce n’est pas un aspect stratégique pour Datatweet, ne
pas le traiter peut s’avérer dangereux pour la pérennité de son développement.
Ces deux parties ont pour but ultime d'améliorer l'efficacité de la société : en effet, en réduisant le temps de
traitement manuel (création d'un client, maintenance infra...) tout en maintenant des critères de performance
et de maîtrise à des niveaux acceptables, la société sera en mesure de répondre aux demandes croissantes
de ses clients, tout en dégageant du temps pour se concentrer sur son cœur de métier (développement de
l'activité et évolutions de la solution). De plus une plus grande automatisation améliorera la qualité de
service, et limitera les risques liés à la sécurité.
Cette industrialisation du SI facilitera de surcroît les évolutions fonctionnelles de l’offre Datatweet. En effet
un SI solide, industrialisé, et évolutif, permet de supporter les nouvelles fonctionnalités envisagées par la
société (rapport de “e­réputation” public hebdomadaire, mise à disposition d’API pour ses clients pour
intégrer des rapport Datatweet au sein même de leur SI…).
10/26

11. 2. Mesure
KPI de mesure identifiés
Nous avons effectué une série de mesures quantitatives et qualitatives pour identifier les points forts et les
points faibles de Datatweet.
Ces données ont été obtenues par des entretiens qualitatifs, des questionnaires quantitatifs, ainsi que par
des mesures effectuées directement par nos équipes sur une période de 15 jours dans la société (analyse
des logs, prise de temps…). Les tests de charge on été exécutés la nuit pour ne pas pénaliser les clients de
Datatweet.
Performances/Capacité
­ Temps de traitement d’une requête depuis la plateforme SaaS : 4 secondes
Cette prise de mesure est effectuée dans le contexte suivant :
○ 20 clients ouverts sur la plateforme
○ 4 clients connectés
○ Requêtes traitant 400 000 tweets
­ Test complémentaire :
○ Prise de mesure 1 client connecté, et une requête de 3 000 000 de tweets : 10 secondes
­ Temps de mise à disposition des tweets : 1 minute (GNIP)
­ Taux de tweets disponibles par rapport à l’ensemble des tweets postés : 100%
­ Maximum de tweets traitable sans ralentissement (2014) : 1 000 000
­ Simulation de l’augmentation du nombre de Clients simultanément connectés et mesure du temps
moyen d’une requête de référence (400 000 tweets traités) exécutée sur tous les postes clients
(simulés par des machines virtuelles)
­ 1 Client ⇒ 4 secondes
­ 5 Clients => 4 secondes
­ 10 Clients => 10 secondes
­ 15 Clients => 1 minutes ; note la GUI client est ralentie
­ 20 Clients => non mesurable ; la plateforme Datatweet n’est plus utilisable
Sécurité
­ Sécurité: firewall géré par le client
­ Disponibilité des serveurs dédiés: pas de garantie en cas de panne.
­ Pas de définition d’un mode dégradé qui pourrait parer à un manque de ressource provisoire
­ Traçabilité ­ archivage des logs: 2 ans
Élasticité
­ Temps de mise en place d’un nouveau serveur physique : 4h
­ Temps de mise en place d’une nouvelle VM : 15 minutes
Qualité processus :
­ Temps moyen d’ouverture d’un nouveau client : 3 jours
­ Temps moyen de maintenance SI / jour : 4 heures
­ Temps de réponse à une question client : 6 heures
­ Temps de résolution d’un incident : au plus vite, pas de SLA.
11/26

12. ­ Temps de mise en prod d’une correction : une fois/mois
­ Temps de mise en prod d’une évolution : 3 fois par mois
Définitions des tâches avec temps moyen passé par mois et leur classification en termes de valeur ajoutée :
Tâches Valeur ajoutée?
Temps passé en
heures par mois
Monitor PLTF Faible 40
Ajout Serveur Faible 24
Livraison Bug Faible 23
Reboot des VMs (maintenance OVH) Faible 10
Alertes OVH (console) Faible 4
Suppr. client Faible 0
Bug Fix Moyenne 36
Assistance Moyenne 32
Ajout client Moyenne 20
MongoDB Forte 3
GNIP Forte 2
12/26

13. 3. Analyze
Problèmes identifiés
Voici les problèmes mis en lumière à partir des mesures quantitatives et des entretiens qualitatifs effectués:
1. Temps passé sur la gestion manuelle des SI sur des tâches avec une faible valeur ajoutée
2. Risque lié à la confidentialité des données
3. Processus ralentis par la structure SI
4. Risque lors d’un besoin fort d’élasticité pour assurer la robustesse du système en cas de montée de
charge
5. Dépendance à un seul fournisseur de données
La structure SI est adaptée à une start­up mais pas assez structurée et puissante pour affronter l’évolution
forte de l’activité à venir. De plus le SI support et les processus sont trop faibles.
Analyse des causes profondes
Tout d’abord nous allons étudier de manière approfondie les résultats des mesures liées aux actions
manuelles effectuées sur le SI, en fonction du temps passé, et de la valeur ajoutée (en terme d’avantage
compétitif métier) de l’action effectuée :
La tendance suivante apparaît : plus de 63% du temps passé sur la gestion du SI l’est sur des tâches avec
une faible valeur ajoutée.
13/26

14. Si l’on analyse le détail de ces tâches, trois catégories consommatrices de temps et à faible valeur ajoutée
ressortent :
­ Le monitoring
­ Les actions “infra” basiques
­ La gestion des clients
Quels sont les causes profondes liées à ces problèmes ?
1. La volonté de maîtrise. Pour quelles raisons est­ce si important pour Datatweet? Pour la sécurité
principalement. Dans ce cadre il ressort un manque d’organisation, de structure, et surtout pas de
gestion de la sécurité en tant que telle ­ hormis au niveau développement.
2. Le manque de connaissances et de temps sur l’état de l’art du Cloud computing, la peur de la perte
de maîtrise, du manque de contrôle et de confidentialité : de fait l’élasticité est quasi inexistante.
Une action manuelle est requise pour l’ajout de chaque nouvelle VM. De plus il y a un risque
sous­jacent de sous­dimensionnement en cas d’augmentation forte de l’activité du service, et donc
des possibilités de baisse de performance et d’indisponibilité.
3. Des processus insuffisants ­ et limités à Datatweet ; il n’existe pas de processus définis pour les
relations avec les fournisseurs comme OVH (passages de modifications en production, reboot
serveurs)
4. Un SI support sous développé, et qui ne peut supporter l’activité : beaucoup d’actions manuelles, un
manque d’automatisation, forte implication des ressources de l’entreprise dans des actions sans
valeur ajoutée.
En conclusion le coût de non­qualité dans la maîtrise de l’infra est énorme (environ 5 jours homme/mois)
pour une entreprise de 7 personnes avec 20 clients. Si le nombre de clients augmente, cette tendance sera
accentuée, et les risques liés ne feront qu’augmenter.
Le risque est accentué par une infrastructure SI peu flexible, et des processus “maison” non­industrialisés.
Techniquement, une solution permettant l’élasticité du SI est indispensable pour améliorer l’efficacité du SI à
répondre aux demandes métier (nouveaux clients, requêtes plus importantes) et garantir la disponibilité du
SI en cas de fluctuation des besoins de ressources, par exemple lors d’un pic de charge coté client.
Choix de l’axe à traiter
En termes de priorités, les choix stratégiques d’architecture sont à remettre en cause. Ce n’est pas
uniquement une question d’infrastructure, mais bien également de processus à redéfinir et de SI
“transverse” à améliorer.
Dans le cadre du projet, nous analyserons en détail la première partie ­ le SI “core business”, et nous
donnerons des recommandations plus succinctes sur le SI “fonctions tranverses”.
14/26

15. Diagramme des causes profondes
Fiches labels
La mise en lumière de ces causes profondes nous permet de définir des points de contrôle qui permettront
de résoudre les problèmes identifiés et d’améliorer de manière continue la qualité de service de Datatweet.
Les fiches labels abordent la sécurité, l'élasticité, la disponibilité, la bande passante et la gestion d’un type
de demande : les incidents. Ces aspects ne sont pas exhaustifs mais sont apparus comme les plus
critiques.
Le détail des fiches labels se trouve en annexe à ce document.
15/26

16. 4. Improve
Nos analyses ont indiqué que la situation actuelle ne répondait pas aux besoins d’évolution du SI de
Datatweet. Nous en avons déduit les principaux facteurs clés de qualités, à savoir: la performance, la
sécurité, la localisation des données, l'élasticité, l’intégration des processus métiers et les coûts
d’exploitation, afin d’identifier une solution du marché pouvant répondre à ces besoins.
Nous allons comparer ces critères par rapport à différents scénarios possible et ainsi déterminer la meilleure
solution:
Solutions
No. Critères clés
Serveurs
dédiés
Cloud
public
Cloud
hybride
Cloud
“dédié”
Nombre
d'importance
1 Performances ­ + + ++ 1
2 Sécurité ­ + + ++ 3
3 Localisation ++ ­ ­ ++ 4
4 Elasticité ­ ++ ++ + 5
5 Processus métiers ­ + + ++ 6
6 Coûts d'exploitation ­ ++ ++ ++ 2
Somme des ++ 1 2 2 5
Somme des + 0 3 3 1
Somme des ­ 5 1 1 0
● Performances: la solution actuelle ne répond pas aux exigences de performances de la société
Datatweet. L’offre Cloud “dédié” d’OVH offre le meilleur niveau de performances avec un hardware et
un réseau 100% dédiés. Le Cloud public offre de bonnes performances car la plateforme de
virtualisation est gérée par OVH. Dans le cas du cloud hybride, les performances sont garanties en cas
de débordement sur le cloud public, mais pas sur les données hébergées sur les serveurs du client.
● Sécurité: ce critère regroupe la disponibilité, la confidentialité, l’intégrité et la traçabilité des données. La
solution actuelle ne permet pas d’y répondre car Datatweet ne dispose pas des moyens et des
compétences pour assurer la sécurité des données. Le cloud hybride et public offrent également un bon
niveau de sécurité, mais Datatweet ne souhaite pas que ses données se trouvent sur une plateforme
partagée avec d’autres clients. Enfin, l’offre cloud dédié garantit le meilleur niveau de sécurité avec des
SLA à 100% sur le réseau et le stockages et des SLA de 99,99% sur les serveurs hosts. De plus, l’offre
cloud dédié est certifiée ISO27001.
● Localisation des données: la société Datatweet veut s’assurer de la localisation exacte des données.
Seuls les serveurs dédiés et l’offre cloud dédié proposent cette garantie.
● Elasticité: les offres cloud public, hybride et dédié permettent d’absorber les pics de charge. Néanmoins,
la capacité d’élasticité est limitée dans le cloud dédié par l'espace dont dispose l'infrastructure détenue.
16/26

17.
● Processus métiers: par rapport aux autres offres, le cloud dédié offre la maîtrise et l’agilité nécessaire
au SI pour permettre à Datatweet l’intégration des processus métiers basés sur le référentiel ITIL.
● Coûts d'exploitation: le cloud permet grâce à la virtualisation de consolider les serveurs ainsi que les
applications. Conjugués au “pay as you go”, il facilite la maîtrise des coûts d’exploitation.
Après comparatif, la solution “cloud dédié” d’OVH a été retenue.
Elle répond aux critères majeurs et critiques pour l'activité de la société:
● Performance: le cloud dédié offre suffisamment de puissance de calcul, grâce à l’élasticité, et
d’espace de stockage pour permettre à la base de donnée MongoDB de traiter des requêtes clients
sur plusieurs millions de tweets. La bande passante est suffisante pour que tous les clients puissent
se connecter en même temps.
● Maîtrise: le cloud dédié est le seul qui permette de s’assurer de la localisation exacte des données.
La maîtrise intégrale de l’infrastructure facilite l’intégration des applications et des processus
métiers. Les coûts d’exploitation sont également mieux maîtrisés.
● Sécurité: OHV garantit une disponibilité de l’infrastructure proche de 100%. Les connexions
extérieures sont sécurisées par des solutions Anti­DDoS et VPN SSL. Le cloud dédié est certifié
ISO 27001. L’attestation SOC 1 type I atteste qu’OVH a bien défini et mis en place des contrôles
pour la protection des données de ses clients
Le principal changement dans notre projet est la migration des serveurs physiques de la société Datatweet
vers l’offre cloud dédié d’OVH. Cette migration nécessite la virtualisation de la plateforme Datatweet. Un
mode de fonctionnement dégradé de la plateforme est également défini ; il implémente les critères de
qualité définis par Datatweet (i.e. accessibilité de l’interface prioritaire sur le flux GNIP).
Les principaux gains de cette solution sont les suivants:
­ Excellents niveaux de sécurité et de performance;
­ Les processus métiers sont plus efficaces car basés sur les bonnes pratiques ITIL;
­ Les coûts d’exploitation sont maîtrisés;
­ L’élasticité permet de répondre plus efficacement aux besoins métiers.
17/26

18.
Les échanges sont décrits dans le schéma suivant :
Planning de migration:
Le planning s’étend sur 2 mois, du 6 avril au 29 mai 2015 et comprend deux phases:
● une phase de build, qui correspond à l’analyse de la solution cible et du budget;
● une phase de run, avec la migration des serveurs et des données, ainsi que la recette.
Budget prévisionnel:
Build Coût Run Coût
Analyse de la solution 5 000
Migration des
serveurs
10 000
Définition du budget 5 000
Migration des
données
20 000
Sous­total 10 000 Sous­total 30 000
Total 40 000
Les tâches d’analyse de la solution cible et de définition du budget comptent chacune 10 jours­homme et
sont facturées 500€ par jour.
18/26

19. Les tâches de migration des serveurs et des données font appels à plusieurs équipes de spécialistes, ce qui
explique qu’elles soient facturées plus cher, respectivement 1 000€ et 2 000€ par jour.
Planning des ressources:
Les ressources intervenant sur le projet ont été réparties de la façon suivante:
● Le chef de projet supervise toute la phase de BUILD et de RUN;
● L’architecte technique intervient dans l’élaboration de la solution et apporte son expertise technique
dans la phase de migration des serveurs;
● Le responsable MOA apporte son expertise métier dans la phase de migration des données;
● L’équipe infrastructure prend en charge toute la phase de RUN.
Prévention des défaillances (FMEA):
Etapes Erreurs potentielles Causes potentielles Contre­mesures
Migration des serveurs Plantage serveur Panne matériel Serveurs de backups
Migration des serveurs Mauvaises performances Besoins mal définis Elasticité dans le cloud
Migration des données Données corrompues Erreur de copie Backup des données
Migration des données Données manquantes Manque de volumétrie Disques en spare
Migration des données Données piratées Captation transfert Canal de transfert sécurisé
Process sigma du pourcentage de tweets traités sans erreur:
Ancien Nouveau
1. Déterminer le nombre d'opportunités de défauts par unité O= 1 1
2. Déterminer le nombre d'unités traitées N= 10 000 10 500
3. Déterminer le nombre total de défauts D= 365 125
4. Calculer le nombre de défauts par opportunité DPO=D/(NxO)= 36 12
5. Calculer le rendement (1­DPO)x100= 96,40% 98,80%
6. Relever la valeur du "Process sigma" dans une table Sigma= 3,3 3,8
19/26

20. 5. Control
Suite à la mise en place de cette nouvelle solution décrite en partie 4. (“Improve”) pour répondre aux
besoins d’amélioration du SI “core business” décrits en partie 3. (“Analyze”), nous allons maintenant détailler
nos recommandations afin de permettre à Datatweet de tirer profit au maximum de ces nouveaux outils, en
conservant et améliorant continuellement sa qualité de service au travers des 5 indicateurs clés identifiés
précédemment.
Les contrôles
Suite aux points identifiés par notre analyse, des labels (KPI) ont étés définis. Leur objectif est de cadrer les
points clés d’une solution pouvant soutenir la croissance de datatweet. Ces KPI assureront la continuité puis
l’amélioration continue de la qualité de service.
Pour cela des contrôles définis et réguliers seront pratiqués selon les procédures définies dans les fiches
labels. Selon la logique de la roue de Deming, ils correspondent à l’étape “Check”.
Afin d’améliorer la qualité de service, ou à défaut de la maintenir à un niveau acceptable, deux types
d’actions (“Act”) seront entreprises suite au résultat de la mesure du KPI :
­ Premièrement des actions de corrections immédiates : le but est de régler le problème mis en
lumière par le point de mesure, dans le but de faire revenir le KPI à un niveau acceptable en
fonction des seuils définis en amont (“Plan”),
­ Deuxièmement des actions d’améliorations : le but est d’identifier la cause profonde du problème,
pour les analyser et définir des actions pour empêcher le problème de se produire à nouveau. Bien
sûr les actions devront être analysées (coût, besoin, …) avant implémentation.
Enfin, une nouvelle série de contrôles permettra de vérifier les résultats des actions correctives entreprises.
Toutes ces étapes de contrôle et d’amélioration du SI reposent sur une double mécanique :
­ Des rôles et responsabilités clairement définis chez Datatweet
­ Un contrat de service précis, qui permet de donner maitrise et confiance à Datatweet sur des
aspects du service gérés par OVH. Pour cela le contrat doit reprendre les mêmes points
structurants, définir des seuils d’alertes, des responsabilités, et des contreparties en cas de non
respect des clauses. Ce contrat est détaillé en annexe.
20/26

21. Les outils de pilotage
KPI Actions de correction
envisageable
Actions d’amélioration envisagable
KPI#1 (sécurité) ­ Audit : corriger le problème
(révoquer des accès…)
­ PenTest : identifier la faiblesse,
corriger le code ou mettre en place
une règle complémentaire
­ Audit : Améliorer les processus (ex :
départ d’un employés, mise en production
d’un changement ou d’une correction…),
automatisation de certaines actions, pour
éviter qu’elles ne soient oubliées,
campagnes de prévention...
KPI#2 (indisponibilité) ­ revenir sur une version de la
plateforme précédente car plus fiable
­ communiquer le planning de
maintenance en interne et le
respecter en cas de livraison
­ redonder provisoirement certains
équipements OVH ou applicatifs
Datatweet
­ communiquer procédure de
contournement à nos clients
­ revoir conception du SI pour permettre
une maintenance par module => limiterait
l’indisponibilité perçue
­ mettre en place une maintenance
préventive (OVH+Datatweet)
­ améliorer process de Release
Management (plus de tests E2E)
­ automatiser le contournement
KPI#3 (bande passante
réseau)
­ provisoirement augmenter la bande
passante ou la configuration de
certains équipements ou les redonder
­ passer les requêtes Datatweet sans
impacts client pendant la nuit
­ optimiser les flux GNIP en regroupant les
requêtes des clients
­ implémenter des requêtes différées et
étudier une offre commerciale attractive
pour inciter nos clients à passer les
requêtes la nuit
­ établir les statistiques des tweets dans le
but d’anticiper les besoins de bande
passante
KPI#4 (incidents) ­concentrer ses efforts sur les
incidents majeurs qui impactent les
clients et le business
­définir des indicateurs de seuil sur
l’outil de supervision pour distinguer
incidents et avertissements et
détecter les incidents plus rapidement
­étudier l’implémentation du processus ITIL
de gestion des problèmes pour traiter les
causes racines des incidents.
­ étudier la création d’une équipe de
résolution d’incidents “niveau 2” sur de
l’expertise métier.
KPI#5 (élasticité) ­faire un audit rapide des ressources
actuelles pour mieux anticiper les
besoins d’élasticité futurs.
­faire une revue des environnements
de travail virtuels de chaque client
pour les rendre plus “propres” et les
délivrer plus rapidement.
­étudier l’évolution vers le cloud hybride
pour améliorer les performances
d’élasticité.
­ améliorer le process interne Datatweet
pour mieux anticiper les besoins métiers
(i.e. nouveaux clients) et donc mieux lisser
les demandes de capacités
­ étudier les débordements dans un autre
data center OVH en France ou chez un
partenaire d'OVH en France
Tableau de Bord
Un tableau de bord opérationnel permet de piloter le SI de Datatweet et donc d’améliorer la qualité du
Qualité du Service d’eReputation.
21/26

22. Il est construit par Datatweet et revu de façon mensuelle avec ses partenaires. Il peut être publié sur le site
internet de Datatweet, partiellement, comme gage de garantie de la qualité de service.
Catégorie Etat
(vert/orange/rouge
)
Tendance
(↗ → ↘)
KPI
Valeur
Actions immédiate Action d’amélioration
Sécurité
↗
Sécurité
14,3% de points KO:
GO
Erreur : accès ouvert pour un
développeur ne travaillant plus
chez DT
Correction : fermer les accès
Amélioration : revoir le
processus de gestion
des changements
(départs/ arrivés) voir
l’automatiser pour limiter
les erreurs
Disponibilité
↗
Disponibilité
plusieurs clients n’ont
pas pu se connecter
Un incident le 25/12/2014
indique qu’un pic de charge n’a
pas pu être absorbé par la
plateforme cloud. La plateforme
était indisponible pour plusieurs
clients.
Correction:’ajout en urgence de
serveurs physiques d’OVH.
Analyser les ressources
du cloud dédié pour
déterminer si elles sont
suffisantes.
Performance
↗
Bande passante
utilisation de la bande
passante à 115%
Congestion sur le réseau lors
d’un pic de charge pendant les
fêtes de fin d’année.
Le log du 25/12/2014 indique
que des clients ont fait des
requêtes simultanées en très
grande quantité.
Définir des seuils
d’alerte plus pertinents
sur les liens réseaux
pour prévenir les pics de
charge.
Maîtrise
↗
Gestion des incidents
incident bloquant à
solutionner dans les 4h
Incident majeur le 25/12/2014.
Certains clients n’ont pas pu se
connecter.
L’incident a été géré en
urgence par une cellule de
crise.
Analyser les causes
racines de l’incident.
Performance
↗
Elasticité
charge au niveau CPU
des serveurs à 120%
L’incident du 25/12/2014
indique que les CPU des
serveurs n’étaient pas assez
puissants pour absorber la
charge.
Des serveurs ont été rajoutés
par OVH en urgence.
Refaire une étude sur
les besoins réels et les
capacités en élasticité
de la plateforme
22/26

23. Backlog
Le backlog recense la liste des actions en cours. Son objectif est d’aider à la priorisation des actions sur des
critères d’impact métier et de difficulté technique. Il est construit en collaboration avec les partenaires de
Datatweet.
Sondage
Datatweet propose à ses clients un sondage en ligne trimestriel dont l’objectif est de recueillir les remarques
et les propositions dans le but d’améliorer la qualité de service générale de la société et de comprendre
quelle est la qualité de service perçue par ses clients.
Réunion
Datatweet met en place une réunion téléphonique tous les seconds mardi de chaque mois avec ses
partenaires. L’objectif de cette réunion est de :
● Faire les points les actions en cours,
● Établir de nouvelles actions si besoin,
● Mettre à jour le Backlog et le prioriser,
● Mettre à jour le Tableau de Bord
23/26

24. Conclusion
Suite à ce projet, le SI “core business” a atteint le niveau de qualité qui va permettre à Datatweet de
s'appuyer sur des systèmes et des processus solides pour son développement. Il sera en mesure de
supporter l’activité croissante de la société, qui pourra grâce aux outils (KPI) mis en place améliorer la
qualité de service de manière continue.
La prochaine étapes est clairement identifiée : il est nécessaire de faire le même travail d’industrialisation
avec le SI “fonctions transverses”. En effet ce dernier doit être optimisé tant en termes techniques qu’en
termes organisationnels, afin de pouvoir soutenir au maximum l’activité de Datatweet. La jeunesse et la forte
croissance de la société suggère que des logiciels SaaS du marché pourraient à moindre coût constituer
une base idéale à ce SI “fonctions transverses”.
Ce n’est que lorsque ces deux parties du SI seront optimisées et maîtrisées que Datatweet pourra
sereinement appréhender ses évolutions, qu’elles soient liées au volume de clients ou à la nature des
service proposés. Par exemple, l'ouverture de la plateforme par des API semble être une évolution naturelle
et pertinente ­ qui ne pourra se faire qu’au moyen d’un SI performant, sécurisé, et surtout où la qualité de
service est maîtrisée à chaque niveau organisationnel.
24/26

25. Annexes
1. L’interview de Raja Chiky le 17/11/2014. Mme Chiky est une experte reconnue dans le domaine du
Big Data et elle nous a éclairé sur les concepts de la eReputation.
2. Le questionnaire qui nous a aidé à recueillir les besoins de Datatweet. Il contient ses réponses.
3. L’analyse de l’offre GNIP, fournisseur pour Datatweet.
4. L’analyse de l’offre OVH, fournisseur pour Datatweet.
5. La charte du projet.
6. Le sondage client qui va aider Datatweet à recueillir la qualité de son service telle qu’elle est perçue
par ses clients.
7. Aperçu des indicateurs qualité entre Datatweet et son fournisseur OVH
25/26

26. Remerciements
Toute notre équipe souhaite remercier l’équipe de Visibrain, en particulier Nicolas Huguenin et
Jean­Christophe Gatuingt, qui nous ont accordé beaucoup de temps, afin que cette étude soit la plus
réaliste et intéressante possible.
Nous voulons également remercier Mme Raja Chiky, pour avoir partagé avec nous sa vision et ses
connaissances sur le traitement de données massives.
26/26