1.
–1–
– PROJET SOCLE
1. OBJECTIF DU PROJET SOCLE
2. ORGANISATION DU PROJET SOCLE
3. TRAJECTOIRE ET DATE CLÉS DU PROJET SOCLE
4. BÉNÉFICES DU PROJET SOCLE
5. ARCHITECTURE DU PROJET SOCLE
a) OBJECTIFS DE LA REFONTE
b) ARCHITECTURE APPLICATIVE DETAILLEE
c) ZOOM SUR LES COMPOSANTS CLES
d) RETOUR SUR EXPERIENCE

2.
–2–
– OBJECTIF DU PROJET SOCLE
Core Renaissance

3.
–3–
–
OBJECTIFS DU PROJET SOCLE
Refonte
ISO-FONCTIONNELLE
du site et des outils de
back-office, autour
d’un SOCLE DE
DONNEES UNIFIE
Un périmètre touchant
l’ensemble des applications Cœur de métier
Rénover et simplifier le SI, pour mieux
servir les métiers
30 Mars 2015
Bascule BB2
Socle : Une
étape majeure
du SDSI
24 Juin 2015
Bascule BB3
8 Déc. 2014
Bascule BB1
Rationnaliser et
homogénéiser les
données au sein du SI
Rationnaliser
l’organisation des
fonctionnalités entre
les différentes couches
de l’architecture SI
Simplifier l’architecture
globale du SI

4.
–4–
– ORGANISATION DU PROJET SOCLE

5.
–5–
–ZOOM SUR LA REPRISE DES DONNÉES
ORGANISATION PROJET SOCLE
Pour le projet Socle, l’APEC a fait le choix de s’appuyer avant tout sur ses
collaborateurs, pour développer les savoir-faire internes
 8 groupes de travail pilotés par les collaborateurs de l’Apec
 Moins de 10 personnes par GT (sauf GT2 avec quelques pointes à plus)
Piloté par les équipes de l’Apec
Comité de Pilotage Commanditaire
Chef de
Projet
GT 1
Spécifications,
Paramétrages &
Recette
GT 2
Développement &
Intégration
GT 3
Homologation
GT 4
Reprise des
données Socle
GT 5
Infrastructure
GT 6
Connexion SI
GT 7
Décisionnel &
Finance
GT8
Accompagnement
Cellule Projet
PMO
Chaque GT est chargé d’organiser son intervention en fonction du périmètre global à traiter lot
par lot, tout en se synchronisant avec les autres GT dont il dépend ou auxquels il contribue. Il
est dirigé par un responsable qui répond de l’avancement des travaux qui lui sont confiés.

6.
–6–
– TRAJECTOIRE ET DATES CLÉS

7.
–7–
– TRAJECTOIRE
Dans une perspective de minimisation des risques de déploiement, une trajectoire en « tâche
d’huile » a été définie.
Le projet a procédé en trois cycles enchaînant chacun les étapes suivantes :
- Développement de nouvelles briques applicatives
- Bascule à blanc simulant en environnement de tests ou de pré-production la reprise des
données et la bascule des anciennes aux nouvelles applications
- Recette technique et métier, et correction des anomalies rencontrées
Une fois la troisième bascule à blanc validée, les applications du socle étaient prêtes pour leur
bascule réelle, c’est-à-dire leur mise en production dans les environnements utilisés par les
métiers et les visiteurs du site APEC.fr
Cycle 1, ponctué par
une bascule à blanc
Cycle 2, ponctué par
une bascule à blanc
Cycle 3, ponctué par
une bascule à blanc
Bascule réelle

8.
–8–
– APPROCHE ET DATES CLÉS
2014 2015
T1 T2 T3 T1 T2 T3 (Juillet)
Front-Office (APEC.fr)
Back-Office et satellites
Reprise des données
Extractions pour SI
décisionnel / Finance
Bascule à
Blanc 1
BB1 BB2 BB3 BR
Bascule
réelle
Bascule à
Blanc 2
Bascule à
Blanc 3
Fiabilisation
de la chaîne
de migration
Fiabilisation
de la chaîne
de migration
Web services, Connexion SI
Cette trajectoire en tâche d’huile s’est traduite par le déploiement graduel du périmètre en
quatre étapes.

9.
–9–
– BÉNÉFICES

10.
–10–
–
AUJOURD’HUI, UN NOUVEAU SOCLE
Un site rénové
Des évolutions
métiers facilitées
Des données
centralisées
l’APEC dispose d’un socle technique flambant neuf
pour proposer de nouveaux services à ses clients
Socle : une
innovation
technique au
service des
innovations
métiers
Un socle technique performant et de dernière
génération qui permet:
Une meilleure production des contenus
sur APEC.FR
Des fonctionnalités techniques natives au
services des fonctionnalités métiers
Des développements de nouvelles
fonctionnalités métiers plus agiles et moins
couteux sur l’ensemble des applications
Des possibilités de développements
nouvelles et innovantes
Une maintenance facilitée
Un délai optimisé
Une bascule réelle avancée
de 4 mois
Fin prévue des travaux :
Fin 2015
Fin réelle des travaux :
Juillet 2015

11.
–11–
– ARCHITECTURE SOCLE
PRÉSENTATION DE
L’ARCHITECTURE TECHNIQUE
DU SYSTÈME D’INFORMATION

12.
–12–
– OBJECTIFS DE LA REFONTE
• Moderniser la pile logicielle :
- Anticiper la faisabilité technique des fonctionnalités de demain
- Réduire les délais de maintenance, évolutions
- Gagner en performance, fiabilité et en scalabilité
• Factoriser les composants logiciels pour simplifier l’architecture :
- Faciliter l’exploitation et la supervision de la plateforme
- Réduire les couts
• Responsive design pour le web
• Ne pas impacter les partenaires externes
• Volonté forte de construire autour de la donnée

13.
–13–
– OBJECTIFS DE LA REFONTE
Architecture applicative macroscopique avant refonte

14.
–14–
– OBJECTIFS DE LA REFONTE
Echanges
Externes
Front-Office
Services Métiers
Mise en place de
l’infrastructure cible sous Windows
Socle de Données
Back-Office
Extractions pour Décisionnel et Finance
/ Services RESTFul
Real Time
Avec Salesforce :
Connexion de
Salesforce
Connexion des
satellites et
partenaires
Architecture applicative macroscopique cible

15.
–15–
–
• Particularités
- Serveur web jeune utilisé pour la 1ère fois en 2004
- Robuste et très performant en cas de fort trafic
- Gestionnaire de cache
- Configuration très simple
- 22% d’utilisation sur le million de sites les + visités au monde.
• Load balancer sur les frontaux web et affinité de session
• Mise en cache des pages ainsi que les appels rest pour le détail des offres
• Caches mis en RAM pour plus de performance
• Redirection pour les Urls du legacy
• Mise à disposition de ressources statiques (site https://histoiresdeliens.apec.fr )
NGINX

16.
–16–
–
• CMS JAVA
- Fournit une boite à outils technique java dense (Spring, tuckey, drools, OSGI…)
- Création de pages et contribution aux articles
- Représentation des données sous forme de nœud (via Jackrabbit)
- Connectivité ( ExternalDataProvider, Intégration de briques Externes)
- Exposition de points d’entrées rest via des Controller Spring
- Bibliothèque de composants disponibles par défaut
- Gestion des droits avancées pour la contribution
- Mécanisme de modules pour la partie développement
• Avantages
- Déploiement des modules à chaud grâce via OSGI
- Architecture cluster
- Multi-sites
- Puissance et rapidité de Jackrabbit
- Import / Export de sites, de pages, de bloc ou de noeud
JAHIA 7 – DIGITAL FACTORY

17.
–17–
–JAHIA 7 – DIGITAL FACTORY
Architecture cluster mise en place
BD SOCLE
SCHEMA JAHIA
MASTER SLAVE 1
LECTURE SEULE
SYNCHRO JCR TOUTES LES 2 SEC
LECTURE/ECRITURE
EDITION PAGES / BLOCS
CONTRIBUTION EDITORIALE
MAJ CACHE NGINX
REQUETE CLIENTE
SLAVE 2 SLAVE 3

18.
–18–
–
• AngularJS : Framework Javascript permettant de faire des applications
web MVW entièrement éxécuté coté client.
• Utilisation d’AngularJS dans des blocs de pages via Jahia
- Rendu utilisateur dynamique – Pas de rechargement de page
- Utilisation du cache Nginx pour les ressources JS et la page Jahia
- Diminution de la charge serveur : fait uniquement passe plat pour les services
- Permet de supporter plus de trafic
• Malheureusement, Google ne sait pas encore exécuter le JS lors du crawling des
pages
• Mise en place d’un serveur utilisant la librairie Phantom JS pour générer une version
html des pages crawlable par Google.
ANGULAR JS ET PHANTOM JS

19.
–19–
–
• PDS : Production de services
• Outils de Back Office (offres, cv, comptes cadres, comptes recruteurs)
• Entièrement réalisé en Angular JS
• Utilisation d’un serveur NodeJS pour la gestion des sessions
• Consommateur des services rest
PDS

20.
–20–
–
• Services web REST ( Resin  Tomcat, ORM : MyBatis)
• Point d’accès à la base de données pour tous les applicatifs
- Contient toutes les règles de gestion métiers
- Mutualisation des développements entre le front et le back office
- Garant de la sécurité « fonctionnelle » d’accès au données
- Garant de l’intégrité des données du schéma SOCLE (Lecture / Ecriture)
• Gestion de l’indexation avec SolR
• Envoi de mail transactionnel
• Gestion de l’upload des documents
SERVICES RESTFULL

21.
–21–
–
• CRM : Salesforce – Utilisé pour la gestion et le suivi des consommations de
services de l’APEC
• INFORMATICA : ETL (Extract-Transform-Load) partenaire avec Salesforce
• Processus métier planifier (batch sur les données)
- Tous les batchs sont traités via Informatica
(ex : suspension des offres)
- Toutes opérations sur les données se font via les services REST
• Synchronisation des données en temps réel
- De la base SOCLE vers le CRM (ex : comptes)
- Du CRM vers le schéma de réplication
• Alimentation du décisionnel
INFORMATICA & CRM

22.
–22–
–
• Oracle
• Réplication en temps réel sur une base de backup ( utilisée en cas de failover )
• Un schéma avec toutes les données métiers ( SOCLE )
• Sur la même base, une copie des informations du CRM dans un schéma spécifique
pour centraliser l’information
• Un schéma est dédié au fonctionnement de JAHIA
• Seuls les services ont le droit d’écrire dans le schéma SOCLE afin de garantir
l’intégrité des données
BASE DE DONNÉES

23.
–23–
–
• Très satisfait de l’architecture en production
- Plateforme performante et stable
- Maintenance et évolutions simplifiées
- Objectifs sont atteints
• CMS Jahia
- Prise en main un peu complexe
- Généraliser l’utilisation AngularJS
- Effectuer les montées de version est préférable
• Utilisation de Jahia pour d’autres usages (ex : intranet)
RETOUR SUR EXPÉRIENCE

24.
–24–
–
…Merci de votre attention !
Questions / réponses