kokou Agbedanou

Étude de cas n°2 : utilisation du cloud public

1. Problématique

Dans cet exemple, l’entreprise GestaForm développe une application de gestion de centres de formation
publics et privés. Cette solution a été développée sous Foxpro il y a maintenant une quinzaine d’années.
Elle a connu un vif succès (environ 200 installations en clientèle) avec une méthodologie d’installation on-
premises. Des composants métier sont utilisés sur des serveurs hostés au sein même de l’entreprise mais
ces serveurs ne sont pas redondés et ils plantent régulièrement. Les mises à jour fonctionnelles ont lieu
désormais une fois par an.

L’équipe est constituée de deux développeurs (les développeurs historiques).

L’application est cependant à bout de souffle pour plusieurs raisons :

ˇ
Concurrence sévère des technologies SaaS.
ˇ
Obsolescence technologique réelle (Foxpro n’est plus maintenu).
ˇ
Lourdeur d’installation on-premises.
ˇ
Cycle de release trop long (1 an).
ˇ
Absence de documentation.
ˇ
Départ futur d’un développeur (préavis de trois mois).
ˇ
Plantage des serveurs hostés (disques pleins à cause des logs, service HTTP arrêté...).
ˇ
Pratique de mise à jour via du FTP.
ˇ
Accès des développeurs aux serveurs hostés.

2. Solution

L’analyse de la situation montre qu’il faut modifier le processus de gouvernance de ce

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
 kokou Agbedanou

projet afin de garantir sa viabilité dans le futur.

La direction générale a donc décidé de recruter un chef de projet et un développeur afin de mettre en place
l’application GestaForm 2.0.

La décision la plus impactante a été de décider de ne pas toucher à l’existant et de partir de zéro (from
scratch) en redéveloppant l’application dans une nouvelle technologie (HTML5, PHP et MySQL) et en
hébergeant l’application dans un cloud public.

En parallèle à la livraison du nouveau service en mode SaaS, un outil de migration de données sera
développé et permettra de transférer les données de la base on-premises vers la base hébergée.

3. Moyens

a. Moyens techniques

Conception applicative

La conception du nouveau logiciel doit prendre en compte la nécessaire séparation de l’application en

couches :

ˇ
Une couche interface utilisateur (IHM) dépourvue de logique métier.
ˇ
Une couche applicative isolée.
ˇ
Une couche bases de données.
ˇ
Utilisation de services web pour dialoguer entre les différentes couches.
ˇ
Découpage de l’application en micro-services qui communiquent entre eux via un bus de
message (en comparaison à une architecture monolithique).
ˇ
Utilisation d’un bus de message (technologie RabbitMQ, XMPP...).
ˇ
Prise en compte de la partie log applicatif en développant une gestion de logs à l’intérieure de
l’application.
ˇ
Utilisation d’un système de messagerie pour les alertes.
ˇ
Gestion du multitenant et de la stratégie de bases de données.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
 kokou Agbedanou

Application coud-ready

L’hébergement doit être pensé pour fournir une mécanique applicative cloud-ready, à savoir :

ˇ
Du fail-over.
ˇ
Du load-balancing.
ˇ
De la scalabilité.
ˇ
De la clusterisation.
ˇ
Une utilisation du multicœur du matériel des serveurs.
ˇ
Une application prenant en compte les principes suivants :

ˇ
Atomicité (une transaction se fait au complet ou pas du tout). Cette propriété fait partie
des propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité) qui garantissent qu’une
transaction informatique est exécutée de façon fiable.

ˇ
Sans état (stateless) : une session utilisateur doit pouvoir être conservée tout au long de
l’utilisation de l’application, quel que soit le serveur sur lequel elle s’exécute.

ˇ
Indempotence (une opération doit produire le même résultat qu’elle soit exécutée une
seule ou plusieurs fois).

Responsabilités du cloud provider

Le cloud provider doit impérativement fournir la redondance matérielle et des protections contre les
attaques venant d’Internet.

Pour la gestion de la sécurité, il est possible d’utiliser des solutions externes à l’hébergeur si ce dernier
n’en propose pas ; par exemple, il est possible d’utiliser une plate-forme comme cloudproxy pour la gestion
des attaques par déni de service (DDOS), des injections SQL…

L’entreprise doit mettre en place une solution de monitoring et la gestion de logs centralisés ; dans
certains cas, les cloud providers proposent ce genre de prestation.

Le monitoring peut être géré par des solutions diverses comme (liste non exhaustive) :

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
 kokou Agbedanou

ˇ
Stack ELK (https://www.elastic.co) pour la gestion des logs applicatifs. Cette suite comprend
les outils Elasticsearch, Logstach et Kibana.
ˇ
Check my Website (https://checkmy.ws/fr) pour le monitoring de sites web (disponibilité,
performances, bon fonctionnement...).
ˇ
Application Performance Management : New Relic (http://newrelic.com) pour la détection
d’erreurs, la charge matérielle, les goulets d’étranglement sur la base de données, les
problèmes de performances…

Les modifications de l’approche cloud

Les équipes devront penser différemment et prendre en compte les points suivants :

ˇ
Compréhension des clauses de garanties de services (SLA) du cloud provider.
ˇ
Compréhension de la tarification (euros par heure, euros par Go consommé ou transféré).
ˇ
Gestion du réseau (adressage public, adressage privé, latence, règles génériques de
firewalling...).
ˇ
Accès au support.
ˇ
Gestion de l’environnement de test.

Benchmarks cloud

Comme tous les clouds ne se valent pas, il vaut mieux effectuer une comparaison. De nombreux sites web
proposent des comparateurs de solutions de cloud, comme par exemple :

ˇ
CloudHarmony : http://www.cloudharmony.com
ˇ
Cloud Spectator : http://cloudspectator.com
ˇ
ServerBearr : http://serverbear.com/benchmarks/cloud
ˇ
ProfitBricks : https://www.profitbricks.com/cloud-performance-testing/
ˇ
Cloudscreener (startup française) : http://www.cloudscreener.com/fr/

b. Moyens humains

Une nouvelle équipe de trois personnes est constituée avec le recrutement d’un chef de

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-
 kokou Agbedanou

projet ayant un profil triple compétence (gestion de projet, technique de développement et expérience du
cloud), d’un développeur expérimenté sur les technologies retenues, ajoutés au développeur historique
restant.

Répartition des ressources

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -5-
 kokou Agbedanou

T1 T2 T3 T4

Développeur 1 Maintenance de Maintenance de Maintenance de Maintenance de

GestaForm 1.0 GestaForm 1.0 GestaForm 1.0 - GestaForm 1.0
formation aux
nouvelles
technologies

Développeur 2 Écriture de Départ début T2 X X

documentation

Transfert de
compétence sur
chef de projet et
développeur 3

Chef de projet Recrutement Mise en place Choix de Maquette

début T1 des nouveaux l’hébergeur Gestaform 2.0 en
outils de SaaS
Transfert de développement -
compétence - démarrage du
Analyse de développement
l’existant -
Gouvernance
nouveau projet

Développeur 3 Recrutement Mise en place Livraison outil de Maquette

début T1 - des nouveaux reprise de Gestaform 2.0 en
outils de données SaaS
Transfert de développement -
compétence - démarrage du
Analyse de développement
l’existant

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -6-
 kokou Agbedanou

c. Moyens financiers

Le tableau suivant présente une synthèse des coûts du projet :

Ordre Chapitre de coût Commentaires OPEX/CAPEX

1 Étude préalable Coût de l’étude préalable (inclure OPEX

les coûts internes et externes si
sous-traitance à un cabinet
spécialisé)

2 Choix du scénario Coût interne (direction OPEX

générale, équipe projet, DAF,
direction marketing, service
clients...), prise en compte des
temps de réunion et de soutenance

3 Frais de recrutement Coût du recours à un cabinet de OPEX

recrutement pour le besoin du
projet + coût interne (entretien de
recrutement, bilan...)

4 Choix du cloud provider Coût interne (réunion, OPEX

déplacement, visite de
datacenters...)

5 Frais de maquettage Plate-forme de tests chez OPEX

l’hébergeur

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -7-
 kokou Agbedanou

6 Licences logicielles Achat de licences diverses pour CAPEX (achat) puis

développer le nouveau logiciel (IDE, OPEX (maintenance)
middleware, bases de données...),
sous forme d’investissement la
première année puis de
maintenance les années suivantes

7 Frais d’hébergement Location mensuelle du service OPEX

8 Frais d’accès au service One-shot de mise en place CAPEX

(FAS) du service (uniquement la première
année)

9 Frais de personnel Salaires CAPEX

4. Conclusion de l’étude de cas n°2

Pour conclure sur cette étude, la transformation digitale d’une application vieillissante en mode SaaS est
un vaste chantier et doit être traitée en tant que projet à part entière incluant une conduite du changement.
Le projet doit être sponsorisé par la direction générale et doit être chiffré au préalable.

Un chef de projet doit être recruté pour la mise en place de la gouvernance du projet, du reporting auprès
du sponsor, de la relation avec les prestataires externes dont le cloud provider, de la gestion de l’équipe de
développement et de la livraison (delivery) du service avec le client.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -8-