Printemps à Deux refonte du système de gestion de liste de mariage sur technologie web

1. Printemps à Deuxrefonte du système de gestion de listede mariage sur technologie web Conférence Hébergement – ebusiness.info Hébergement et exploitation d’une plate-forme web pour une brique d’un SI d’entreprise Benoît Rigaut – directeur technique Printemps.com S.A. brigaut@printemps.com - 9 octobre 2003

2. Printemps.com / France Printemps • France Printemps • Grands Magasins, • 20 magasins en France, • Intégré au groupe PPR, • Activité traditionnelle de Liste de Mariage. • Printemps.com • Filiale de France Printemps, • Gestion des activités web, • Création de la filiale à l’occasion de ce projet business autour de la liste de mariage. 2000 2001 2002 2003 Initialisation du projet été 2000 Version 0 mai 2001 Cadrage et spécifications Réalisation et bascule en juin Ouverture inter-enseigne Lancement du programme grand public

3. Un projet business… et technique • Faire du Printemps le centre d’un programme inter-enseignes PPR de gestion de liste de mariage. • Le SI de gestion de liste de mariage date de 18 ans – Cobol, base de données à plat, consultation par écran passif… • La DSI France Printemps ne souhaitait pas faire évoluer cette ancienne application. • Refonte sur technologie web, sur base Microsoft, et choix du prestataire FiSystem pour le conseil et la réalisation. • Cas classique d’un projet business qui déclenche la reprise en main d’une pièce du SI délaissée, et qui participe à l’arrivée des technologies web en s’attaquant tout d’abord à une pièce satellite.

4. Un choix d’hébergement • La version 0 du projet nous a permis de prendre pied dans une plate-forme d’hébergement web mutualisée à plusieurs enseignes du groupe PPR. • Simplification et factorisation de divers hébergements web orientés à l’époque « coups marketing » • Utilisation de multiples éléments réseaux mutualisés au niveau de la plate-forme PPR (load balancer, reverse proxy, firewall, sonde IDS) et au niveau de l’hébergeur (serveur DNS, robot de backup, etc.). • Mise en place d’éléments de monitoring par l’hébergeur (Exodus à l’époque) sur des URL et des éléments vitaux (SNMP, etc.).  Un choix structurant permettant au projet de se concentrer sur les couches applicatives en simplifiant des décisions de plate-forme bas niveau.

5. Intégration SI interne et externes • La version 1 consiste en une re-écriture complète du système de gestion de liste de mariage, ceci nécessite une reprise des flux l’unissant au reste du SI de France Printemps • Catalogue produit, • Débit de la carte Printemps à Deux par le serveur monétique, • Détails des transactions remontant depuis les caisses, • Dons directs aux caisses, • Gestion des prospects (Pivotal). • Ainsi que s’intégrer avec de nombreux nouveaux partenaires et fournisseurs • SIPS/Atos pour le paiement en ligne, • Catalogue produit Conforama, • Publication du 3615 Printemps, • Envoi de SMS, • Partenaires marchands online, • Éditique, etc.

6. Une plate-forme web typique • Un frontal web (choix de la technologie Microsoft .NET en janvier 2002). • Une couche d’objets métiers (développement en C#, VisualStudio.NET). • Une base de données relationnelle (SQL Server 2000). • Une volonté d’intégrer les différentes interfaces de ce nouveau développement autour de 3 axes forts • TCP/IP, • XML sur HTTP pour le temps réel, • Des transferts de fichiers XML via CFT/XB (Sopra) pour les batchs.  Un développement typique de technologies web qui reste neutre par rapport au choix de la plate-forme logicielle retenue.

7. PRINTEMPS A DEUX Netsize EtHopMinitel! Une plate-forme communicante Caisses Magasins Serveur Monétique Site web partenaire Web Services Web Services HTML Web Services Intranet / Extranet Alertes de dons par SMS printempsadeux.com 3615 Printemps

8. Centraliser pour communiquer • Le choix de la plate-forme d’hébergement nous a aidé dans l’établissement des différents liens nécessaires aux intégrations avec les SI distants. • Les liens internes au groupe PPR ont été facilité par la connectivité des enseignes Fnac et Conforama à la plate-forme centralisée. On engrange ici les bénéfices d’une stratégie de groupe favorisant l’établissement de programmes transversaux en évitant le coût d’interconnexion qui aurait été bloquant. • D’autre part la nature centralisée de la plate-forme web à favorisé l’utilisation de solutions en mode ASP (minitel, SMS, etc.) permettant de se concentrer sur notre cœur de métier en faisant appel à des prestataires externes accessibles via l’internet publique.

9. Exploitation • Bascule en juin 2002 du système de gestion de liste du mariage sur la nouvelle plate-forme. D’où responsabilisation forte autour de l’exploitation, puisqu’une indisponibilité de l’outil se répercute en magasin par un fort mécontentement client. • Établissement d’un contrat de service avec des SLA avec GlidePath pour l’exploitation de la plate-forme. Une période de recouvrement avec l’équipe de développement applicatif est nécessaire pour passer le relais à l’équipe d’exploitation et créer un cahier d’exploitation. • Une procédure longue à mettre en place, tant au niveau contractuel que technique.  Mais une amélioration de la rigueur d’exploitation, en scindant l’équipe de développement applicatif (TMA) de la responsabilité quotidienne de la bonne marche de la plate-forme.

10. Conclusions • Une plate-forme peut remplacer une brique de SI et savoir communiquer avec les legacy applications sans bouleverser l’ensemble. • Elle peut tirer partie de sa nature communicante pour se concentrer sur son cœur de métier et faire appel à des solutions externes spécialisées. • Un hébergement « groupe » donne une base structurante à des projets inter-enseignes de ce type. • Contrairement à un hébergement in-house, on profite d’une équipe d’exploitation spécialisée, après une phase longue de mise en place.

11. Printemps à Deux Questions / Réponses