Présentation préparée pa Denis Zandvliet et Philippe Macret : Comment maîtriser l'intégration du Cloud et du SaaS dans l'entreprise - Forum SaaS et Cloud Métiersdu Club Alliances IBM - novembre 2010

1. Comment maîtriser l'intégration du
Cloud et du SaaS dans l’Entreprise ?
Atelier Club Alliances
26 novembre 2010
Denis ZANDVLIET & Philippe MACRET

2. Page  2
Agenda
Cloud & SaaS : du mythe à la réalité
Comment intégrer du SaaS dans le SI ?
Quelles obligations « SLA » ?
Quelles contraintes juridiques ?
Conclusion : conserver les bonnes pratiques !

3. Page  3
Cloud & SaaS : du mythe à la réalité
– Rupture technologique ?
– Concept marketing ?
– Management de process ?
– Partage de ressources ?
– Hébergement ?
– Application à la demande ?
Les débats sur le « Cloud » font rage !
« au bout du compte, ce n'est qu'une manière
d'héberger des données, des services et des process »
David Linthicum, expert en Cloud Computing

4. Page  4
Cloud & SaaS : du mythe à la réalité
 Pour le GARTNER , l’ASP décolle enfin en se renommant SAAS
 Pour ASPAWAY, L’ASP ou « on Demand » est l’ancien nom du SAAS
 Le SAAS, une solution de demain !
– L’ASP désigne une entreprise qui fournit des services informatiques à ses clients
à travers le réseau…
– Le SAAS est un modèle de livraison d’applications dit locatif où le client n’achète
plus directement une licence physique mais accède à son application via internet
contre une rétribution mensuelle par user ou par ….
– « un logiciel hébergé qui s’appuie sur une structure de données et un code source
communs, partagés entre l’ensemble des clients utilisateurs du service, suivant un
modèle ‘1 à n’, facturé à l’utilisation ou sur abonnement en fonction de critères liés
à l’usage ».

5. Page  5
Cloud & SaaS : du mythe à la réalité
FACILITY MANAGEMENT
– Le (FM) est une solution d’organisation regroupant
sous la responsabilité d’un seul prestataire, la gestion
et la coordination des activités supports nécessaires à
l’exercice du métier d’une entreprise.
– L’opérateur de FM assume les risques et les charges
de la mission pour laquelle il a pris un engagement de
résultats.
– Le succès implique toujours une étroite collaboration
entre le donneur d’ordre et l’opérateur FM.
– Les relations avec l’opérateur FM s’inscrivent dans la
durée et les enjeux sont pris en considération dans un
climat de partenariat privilégié.

6. Page  6
Cloud & SaaS : du mythe à la réalité
Facility Management = INFOGERANCE
– Prise en charge contractuelle de tout ou partie de la
gestion d'un système d'information par un prestataire
extérieur. maintenance corrective, préventive et
évolutive
Assistance et support fonctionnel aux utilisateurs
Surveillance, exploitation et administration
des systèmes et réseaux

7. Page  7
Cloud & SaaS : du mythe à la réalité
TRAITEMENT à FAçON ou SERVICE BUREAU
Le traitement à façon fut la première forme de
« service informatique ».
Le contrat de "traitement à façon" est celui par
lequel le fournisseur traite, sur son matériel et
avec ses programmes, les informations brutes
communiquées par son client qui n’est
généralement pas équipé d’un ordinateur de
puissance suffisante.

8. Page  8
Cloud & SaaS : du mythe à la réalité
Même Langage !
Nouveau ou évolution ?
Adaptation aux nouvelles technologies

9. Page  9
Cloud & SaaS : du mythe à la réalité
Mêmes règles :
– Définition des objectifs attendus
– Faisabilité
– Rôles des partenaires
– Clauses contractuelles
– Réversibilité
– Financières

10. Page  10
Agenda
Cloud & SaaS : du mythe à la réalité
Comment intégrer du SaaS dans le SI ?
Quelles obligations pour les « SLA » ?
Quelles contraintes juridiques ?
Conclusion : conserver les bonnes pratiques !

11. Page  11
SI
L’intégration est-elle possible ?
Des avis assez négatifs :
• Transition d’information par le Web avec risques en
termes de sécurité (confidentialité surtout)
• Cohérences des référentiels structurels difficiles
(modes SaaS ‘figés’)
• Mises à jour difficiles des référentiels et des
informations opérationnelles entre SI et SaaS
WEB
Appli. SI Appli. SaaS

12. Page  12
Comment sécuriser les flux ?
Les solutions existent et sont pérennes :
• Réseau mode VPN
• Mode HTTPS (cryptage)
• Authentification forte des utilisateurs sur leurs postes
de travail (KPI, …)
• Logins bien gérés
• Défenses bien gérées des attaques sur login
Mais les risques restent essentiellement …
… ceux des faiblesses humaines

13. Page  13
Cohérence des Référentiels structurels
• Nécessité d’une cohérence pour consolider les
informations inter-applications (cf. ERP)
• Applications SaaS généralement avec un principe de
paramétrage
• Rechercher la « structure commune minimum »
• Utiliser des tables de codes « analytiques » ou de
« regroupements »
• SI propriétaire des référentiels structurels comptables,
financiers et RH, mais évolutions possibles
• Pas de fichiers communs, mais la mise à jour des tables
peut se faire par messages (XML, …)
La problématique est de fait très similaire à celles
d’applications indépendantes intra SI

14. Page  14
Flux entre SI et SaaS :
le Fonctionnel & l’Organisationnel
• Conventions formelles sur les contenus (périmètres
des données, …) impératives
• Responsabilités à définir formellement sur les rôles en
import et export (instruction des informations, …
validation, …, export, …)
• Principes du WorkFLow à appliquer
• (Semi)-automatisations potentielles
Mais des solutions différenciées
suivant les situations

15. Page  15
Codes Analytiques
Propriétaires des Données ?
Base Comptable Base opérationnelle
Codes Métiers
Application S.I. (interne) Application SaaS (externe)
Codes Analytiques
duplication
duplication
duplication
duplication
Codes Métiers
cohérence
& analyses analyses
cohérence
& analyses
analyses

16. Page  16
Flux entre SI et SaaS : le Technique
• Pas de « transactionnel » inter-applications
• Flux via des Messages inter-applications
• Utilisation de tables fichiers à plat, CSV, … ou en
formats structurés (XML, …)
• Outils de simulation de saisie si pas d’API en import
• Datations des données en import-export
• Gestion des rejets à organiser en temps quasi-réel
• Contrôles par les quantités en export et en import
Traçabilité la plus exhaustive possible

17. Page  17
Exemple de flux (ici : SI vers SaaS)
Application SI Application SaaS
Export
WEB
(VPN ou HTTPS)
Cryptage
Import
Décryptage
Rejets
Contrôle
Quantité

18. Page  18
Les Contrôles des flux d’intégration
• Vérification des cohérences, des effets miroirs, …
• Doivent être outillés, i.e. (semi)automatiques
• Utiliser des datations
• Batchs pour les audits de masse
• Temps réel pour focus (informations sensibles, …)
• Mettre à jour la documentation (pour les règles de gestion,
…)
La traçabilité est impérative

19. Page  19
Intégration SaaS – SI : Axes d’étude
• Volumes échangés
• Fréquence des échanges par type d’information
• Sensibilités des informations
• Propriétés des informations et des données
• Contraintes fonctionnelles
• Contraintes organisationnelles
Donc des axes d’études très classiques,
avec, impérativement,
une approche SYSTEMIQUE

20. Page  20
Agenda
Cloud & SaaS : du mythe à la réalité
Comment intégrer du SaaS dans le SI ?
Quelles obligations pour les « SLA » ?
Quelles contraintes juridiques ?
Conclusion : conserver les bonnes pratiques !

21. Page  21
Quelles SLA ? (Service Level Agreement)
Sécurité physique (accès aux sites, …)
Sécurité IT (serveurs, …, backup, …)
Sécurité logique (cryptage, …)
Temps de réponse
Fonctionnelles

22. Page  22
Sécurités physiques
Vérifier la localisation physique des serveurs
-> Existence de risques de fermes virtuelles
Vérifier les modes d’exploitation et de sauvegarde
(fréquence, …)
Site de Back-up impérativement sur une autre
localisation

23. Page  23
Sécurités logiques
• Risques liés à l’ouverture du WEB
• Qualité des Logins
• Défense attaque sur Login
• Cryptage des trames
• Authentification/ Certification des users et des serveurs
Les solutions sont très classiques

24. Page  24
Temps de réponse
• Nécessaire d’être « suffisant »
• Somme de :
– Serveur, réseau interne hébergeur, firevall, réseau
WEB, firewall, réseau interne entreprise, poste de
travail
• Seule la partie WEB n’est pas directement maîtrisable
• Par type de fonction
• Attention aux pics (clôtures, …)
Consultations
simples
Reportings
complexes
Echelle de temps non linéaire
1 s 1 mn
Durée
Qtté

25. Page  25
SLA fonctionnelles
• Evaluer les volumes échangés et stockés, du démarrage
à la vitesse de croisière
• Estimer les nombres d’utilisateurs par typologie de
profils
• Disponibilité de l’application (7/7 ou 5/7, …)
Définition nécessaire du périmètre
et qualitativement et quantitativement

26. Page  26
Agenda
Cloud & SaaS : du mythe à la réalité
Comment intégrer du SaaS dans le SI ?
Quelles obligations pour les « SLA » ?
Quelles contraintes juridiques ?
Conclusion : conserver les bonnes pratiques !

27. Page  27
Les Rôles
Souvent en multi-parties :
– Client
– Editeur
– Prestataire (conseil, paramétrages, …,
accompagnement, …)
– Hébergeur
Or les contrats multi-parties sont à proscrire !
Concevoir des contrats en cascades biparties,
de préférence avec un maître d’œuvre

28. Page  28
Organisation
ParamétrageHébergement
SaaS
Cascade : Editeur MOE
Client
Hébergeur Conseil
Editeur

29. Page  29
Licences
Organisation
Paramétrage
Hébergement
SaaS
Cascade : Prestataire MOE
Client
Hébergeur Editeur
Prestataire

30. Page  30
Des SLA aux Pénalités
• L’absence de pénalités vide le contrat
• Des pénalités raisonnables
• Quantifications :
– pertinentes
– opérationnelles
– mesurables ET mesurées
– sans conteste
Les pénalités sont faites pour ne pas être appliquées, tout
en garantissant la satisfaction des parties.

31. Page  31
Structure d’un contrat SaaS
Corps du contrat
• Définitions
• Généralités (objet, périmètre, …)
• Licences d’utilisation
• Hébergement
• Exploitation
• Administration
• Support
• Evolutions
• Conditions financières
• Dispositions générales
(juridiques)
Annexes
• Contenu fonctionnel de la
Solution
• Niveaux de service SaaS
• Procédures (support,
maintenance, …)
• Démarrage et durée
• Autres services
• Mise en œuvre de la réversibilité
• Partenaires concernés
• Impacts du Web
• Moyens d’hébergement
• Dépôt des sources
… non exhaustif

32. Page  32
Comment ne pas aller au Tribunal ?
• Conclure des accords bilatéraux, équilibrés
• Définir explicitement le hors périmètre
• Formaliser clairement les obligations de chaque partie
• Veiller à la sauvegarde des intérêts de chaque partie
• Tracer tous les événements (CR, …)
• Toujours rester factuel
« Vis pacem, para bellum »

33. Page  33
Agenda
Cloud & SaaS : du mythe à la réalité
Comment intégrer du SaaS dans le SI ?
Quelles obligations pour les « SLA » ?
Quelles contraintes juridiques ?
Conclusion : conserver les bonnes pratiques !

34. Page  34
Conclusion
• Une application en mode SaaS reste une application au
service d’un métier client
• Evaluer préalablement les contraintes et limites de la solution
fonctionnelle et technique
• Toujours définir professionnellement le contenu de la solution
attendue (mode progiciel)
• Accepter que les interactions entre le SI et le mode SaaS
restent sur le fond des interactions inter-applications
• Veiller aux questions de sécurité … comme d’habitude !  
• Quantifier les prestations par des Unités d’Œuvre dans le
langage du métier client
• Ne pas tomber dans le phénomène de la judiciarisation, mais
anticiper une procédure par un contrat équilibré

35. Page  35
Les moyens diffèrent,
mais le fond reste le même.