Présenté par Anne Gabrillagues (enssensei) et Florence Lyon (Groupe RATP) à Agile en Seine le 20 septembre 2023 Quand on pense à l’agilité dans l’IT on pense le plus souvent équipe(s) en charge du développement complet d’un produit, dans un cadre le plus souvent de type Scrum ou SAFe. Mais dans certains cas la solution la plus pertinente à mettre en œuvre repose sur l’intégration d’un progiciel, travaux souvent réalisés par un intégrateur spécialisé … Peut-on mener ce type de projet en mode agile ? Comment contractualiser avec les différents intervenants, avec en contrainte supplémentaire la nécessité de s’inscrire dans le cadre du Code des Marchés Publics ? Comment lancer ce type de projet ? Cette session sera l’occasion de vous partager nos expérimentations, nos erreurs … et nos apprentissages.

1. 19 & 20 septembre 2023 - Paris, Niort
Intégrer un progiciel en mode agile à la
RATP ? Défi relevé !
Retour d’expérience RATP

2. PLATINUM SPONSOR
GOLD SPONSOR
SILVER SPONSOR
PARTENAIRE

3. Posez vos
questions !

4. Qui sommes-nous ?

5. Anne Gabrillagues
• Coaching d’équipe, d’organisation / agilité à l’échelle et
coaching OKR
• Co-fondatrice de
• Agiliste depuis 2008 (Scrum Master, PO et coach)
• Participation au développement de la
simulation d’apprentissage Kanban
• Conférencière agile et organisatrice de conférences
agiles depuis 2012
linkedin.com/in/agabrillagues
@agabrillaagues

6. Florence Lyon
Transformation Agile du groupe RATP
Responsable Core Team Fabrique Digitale
Transformation Agile Bouygues Telecom
https://www.linkedin.com/in/florence-rivenet-lyon/

7. Connaissez-vous la RATP ?

8. 8
Quand vous pensez à la RATP …
CHOIX #1
OU
CHOIX #2

9. 9
OU
CHOIX #1 CHOIX #2
Quand vous pensez à la RATP …

10. Le groupe RATP a développé un savoir-faire historique unique
d’opérateur multimodal.
+ de 70 ans
d’expérience
9
modes de transport opérés
3e opérateur
de transports urbains
dans le monde
Le transport public,
activité-cœur
15 pays​
780 villes​
16 millions
de voyages par jour
Un leader mondial de la
mobilité durable

11. NOS
SAVOIR-FAIRE
Nous accompagnons
les différentes transformations
urbaines grâce à une large
palette d’expertises :
immobilier, smart city, digital,
télécom, ….
… AU SERVICE D’UNE MEILLEURE
QUALITÉ DE VILLE
DES EXPERTISES COMPLÉMENTAIRES
AU SERVICE DE LA VILLE DURABLE…

12. Un peu de contexte …

13. Culture « projet »
• Le projet type à la RATP n’est pas un
projet IT !
• Les projets d’une durée de 10 à 25 ans ne
sont pas rares, et comportent pour
certains une composante IT
• La durée de vie des applications,
notamment côté industriel et
exploitation, est longue (20 ans par ex.)
• Très forte culture de type « ingénieur »

14. Cadre méthodologique
• Cadre méthodologique global ancré
dans la gestion de projet
traditionnelle, pensé pour des projets
de type génie civil
• Déclinaison « allégée » à destination
des projets IT, très ancrée dans le
Cycle en V et décrivant les modalités
de gestion de différentes typologies
de projet (progiciel, décisionnel,
portage technique, etc.)

15. Prépondérance des
progiciels
Très forte proportion de projets d’intégration de progiciels :
• au service des fonctions supports classiques (RH,
comptabilité, etc.)
• pour outiller les métiers spécifiques du transport :
• GMAO (Gestion de Maintenance Assistée par
Ordinateur)
• Organisation et suivi de l’exploitation des lignes de
bus, métro et tram (commande de services, etc.)
• Déclaration et suivi des problèmes dans les espaces
• Etc.

16. Des contraintes spécifiques
• Respect du Code des Marchés
publics
• Contraintes liées à la Sécurité
ferroviaire
• Le forfait est le mode contractuel
privilégié

17. Répondre aux nouveaux défis
Ouverture à la
concurrence
Modernisation
des Métiers

18. Une transformation ambitieuse

19. S’attaquer au sujet …

20. Modernisation du cadre méthodologique
Réduction du « time to market »,
ou plus précisément du « lead
time »
Centricité utilisateur
Réduction du temps écoulé entre la
réception d’un besoin client et la mise en
service de la solution correspondante
Démarche centrée sur les besoins
utilisateurs, incluant un focus UX, un
pilotage par la valeur, l’implication de
représentants des utilisateurs finaux,
etc.

21. Notre source d’inspiration
L’idée est de reprendre les principes du
Modèle de Delivery de l’Usine Digitale
de la RATP fortement inspiré de Scrum,
fruit de 4 années d’apprentissages :
• Fonctionnement agile éprouvé
• Utilisateurs fortement impliqués tout
au long du projet
• Version d’une application réalisée en
moins de 5 mois en moyenne
• Très haut niveau de satisfaction
utilisateurs

22. La démarche adoptée
Réflexion
alimentée par
des REX projets
Expérimentations
accompagnées
par des coachs
agiles Capitalisation
des résultats
Lancement de
nouvelles
expérimentations
Constitution d’un
groupe de travail
Notre focus du jour

23. Mémento modernisé

24. Mais où est l’agilité ?
Mémento projet Mémento projet modernisé

25. Mais où est l’agilité ?
L’Agilité devient l’approche privilégiée
mais le Cycle en V va continuer à être
utilisé à la RATP
Être agile ce n’est pas seulement
déployer Scrum ou SAFe … C’est avant
tout respecter les grands principes sous
jacents !

26. Démarche
adaptative &
priorisation
continue
Retour aux fondamentaux
Centricité
client &
pilotage par
la valeur
Qualité
intrinsèque
Amélioration
continue

27. Nos expérimentations

28. Etude de faisabilité
et d’opportunité

29. Objectifs de cette étude
Comprendre les besoins du métier et les positionner sur la vue
urbanisée du SI
Identifier les contraintes techniques et les enjeux (cyber sécurité,
performances, RGPD, etc.)
Se forger une conviction concernant la solution à mettre en œuvre :
• Achat / location d’un progiciel (identifier une liste limitée de
progiciels pouvant bien répondre aux besoins)
• Développements spécifiques
• Evolution d’une application existante

30. Mise en place des rôles « agiles »
Représentant le Métier et les
utilisateurs finaux,
accompagnés
potentiellement de référents
Métiers sur des expertises
particulières
Porteur de l'expertise de
création d'un produit digital
et des bonnes pratiques de
gestion de produit
Product Owner Proxy Product Owner Delivery Lead
Garant de l’engagement pris
auprès des Métiers, en
charge de la coordination et
du suivi du projet.
Facilitateur entre l’équipe et
l’éco système IT de la RATP
Confier le rôle de PPO à des
MOA ou AMOA afin de
capitaliser sur leur
connaissance des métiers de
la RATP et leur relation avec
les Métiers

31. Accompagnement de l’équipe
Organisation de formations développées et/ou animées par les coachs du
programme de transformation agile
• Acculturation agile
• Manager agile
• Formation spécifique PO
Accompagnement rapproché par un binôme de coachs agiles expérimentés
(y compris en terme de Delivery Agile) rattachés au programme de
transformation
Invitation à se rapprocher des communautés de pratiques mises en place
(Produit, Delivery Lead, Tech, Facilitation, etc.)
Mise en œuvre d’un accompagnement des nouveaux Delivery Leads
(incluant un parrainage par un DL expérimenté)

32. Prendre une orientation Produit
Utilisation des outils classiques de la gestion de produit pour
la collecte et la consolidation des besoins :
• Vision Produit
• Persona
• Story Map
• Besoins consolidés et priorisés dans un backlog (niveau
épiques et features à ce stade du projet)
• Roadmap orientée produit

33. Se faire une conviction
Réalisation systématique d’une étude « Make / Buy / Reuse » visant à
prendre une décision éclairée concernant la réalisation de
l’application :
• Achat / location de progiciel
• Développements spécifiques
• Evolutions à réaliser sur une application existante
Si l’orientation progiciel est prise, nous réalisons au sein de cette
phase un benchmark des solutions disponibles, incluant de la veille,
des échanges avec d’autres opérateurs du transport, des travaux
avec les éditeurs, la réalisation de POC… Le but est de sélectionner
un nombre très restreint de progiciels (idéalement LA bonne
solution)

34. Nos apprentissages
✓ L’accompagnement à la prise de rôle
des PO et PPO des projets pilotes (à
défaut l’intégration d’un PPO
expérimenté en prestation)
✓ Meilleure implication des Métiers et des
utilisateurs finaux
✓ L’adoption de la boîte à outils de la
gestion de produit (Story Map en
priorité)
✓ La constitution de la liste réduite des
progiciels candidats en amont de la
phase de contractualisation
• Identification suffisamment tôt projets
pilotes
• Biorythme de l’organisation
• Le financement (« Dossier de Demande
d’Investissement »)
• Résister à l’attrait de la « sur-spécification »
• Réaliser de façon efficace l’étude « Make /
Buy / Reuse » et le benchmark des
solutions
Ce qui marche Ce qui reste compliqué

35. Consultation &
contractualisation

36. Objectifs de la phase
Sélectionner et contractualiser de façon efficace avec le fournisseur
retenu :
• Produire efficacement les documents nécessaires
• Proposer un cadre d’organisation projet
• Préparer la phase de négociation avec les fournisseurs en
donnant une bonne maîtrise des principes agiles à l’équipe
projet

37. Adapter les documents à produire
Repartir des modèles de documents mis à jour suite aux derniers retours :
• Cahier des Spécifications Fonctionnelles et Techniques (CSFT)
• Plan d’assurance de la qualité des activités de réalisation (PAQR)
Intégration des livrables typés gestion de produit dans le « cahier des
charges », a minima :
• Backlog niveau épiques et features
• Story Map (version initialisée)
• Cadre de cohérence technique et exigences techniques spécifiques
Co-rédaction du cadre d’organisation projet (équipe + coachs) :
• principes souhaités par la RATP
• Invitation auprès du soumissionnaire à se projeter dans ce cadre et
décrire factuellement l’organisation proposée

38. Le dépouillement
Implication des coachs agiles :
• Intervention couverte par la signature d’un NDA
• Evaluation des aspects organisationnels des différentes propositions
• Participation éventuelle aux soutenances
Evaluer la compréhension et le niveau d’agilité des soumissionnaires
Identifier le compromis possible entre l’organisation proposée par les
intégrateurs et/ou l’éditeur et ce qui a été demandé côté RATP :
• Respect des principes fondamentaux
• Analyse sous l’angle de la gestion de risques

39. La négociation
Négocier le meilleur compromis possible en terme d’organisation. Ne pas hésiter à être
créatif tout en restant fidèle aux principes fondamentaux de l’Agilité :
• Résister à la tentation du dogmatisme
• Challenger la gestion des risques et vulgariser en quoi le mode agile comporte des
techniques de mitigation de risques à tous les niveaux
• Il est parfaitement possible d’intégrer des pratiques agiles dans un fonctionnement
typé Cycle en V
Attention à l’impact de la mise en place d’un fonctionnement agile en terme
d’organisation mais aussi au niveau financier :
• Dimensionnement des équipes, notamment côté RATP
• Charge liée aux ateliers et réunions récurrentes (démonstrations, rétrospectives,
etc.)
• Renoncement à des pistes d’optimisation dans la construction de la solution
• Rejeu régulier des tests de non régression, automatisation des tests, etc.

40. Nos apprentissages
✓ La co-construction du cadre
organisationnel à 4 mains entre
l’équipe projet et les coachs agiles
✓ L’appropriation des principes agiles par
le biais de la gestion de risques
✓ L’intégration de pratiques et principes
agiles dans un cadre Cycle en V
• Résister à l’attrait de la « sur-spécification »
• Utiliser le jargon agile directement dans
les documents de la consultation
• Le niveau de maitrise (voire d’appétence)
de l’agilité de nos fournisseurs
• La cohabitation Forfait et Agilité …
• La crédibilité de l’Agilité à la RATP du
point de vue des fournisseurs
Ce qui marche Ce qui reste compliqué

41. Cadrage

42. Objectifs de la phase
Lancer efficacement le projet avec le fournisseur retenu.
Affiner le besoin et construire une compréhension commune avec le
fournisseur retenu.
Concevoir la solution sur la base du progiciel sélectionné.
Préparer la phase de réalisation en mettant en place les conditions
de succès.

43. Création de l’équipe étendue
Organisation d’un kick off en mode agile :
• Equipe complète : RATP + titulaire
• Partage de la vision
• Aspect « Team Building » à ne pas négliger
Mise en place des conventions et règles de vie en équipe (RATP + titulaire) :
• Prise en main des outils
• Modalités de communication (canaux, délais, etc.)
• Organisation au quotidien
• Colocalisation des équipes autant que possible
Préparer les activités du cadrage :
• Affinage de la démarche de cadrage
• Calage des agendas pour les ateliers et réunions

44. Finaliser l’organisation
Validation de la durée des itérations
• Durée idéale ; 2 semaines
Clarification des rôles et responsabilités
• Utilisation de la matrice des attendus à la place du RACI traditionnel
Clarification des processus documentaires et de validation
• Limitation de la documentation au strict minimum (quid des CR d’atelier par
ex.?)
• Construction de la documentation en mode itératif et incrémental
Validation de la bonne intégration des « cérémonies agiles » dans la comitologie
prévue
• Par exemple : démonstration à chaque CoPil, sanctuarisation des temps de
rétrospective

45. Comprendre et affiner le besoin
Construire une compréhension partagée du besoin
• Présentation du backlog par le PO & PPO
• Sessions d’immersion terrain pour toute l’équipe (titulaire inclus)
• Organisation d’ateliers avec les utilisateurs
Prise en main de la solution
• Formation des équipiers RATP à la solution retenue (version brute),
idéalement sur un environnement mis à la disposition de la RATP
Affinage des besoins au regard de la solution
• Identification des besoins couverts en standard
• Challenge des besoins dont la réponse nécessite des développements
spécifiques
• Définition des parcours utilisateurs (si possible avec un UX Designer)

46. Concevoir la solution
Co-construction de la conception technique
• Interfaces avec le SI RATP
• Identification des prérequis techniques pour la réalisation
• Respect du cadre de cohérence technique, des exigences cyber, RGPD,
performances, etc.
• Mise en œuvre des principes de conception er des pratiques d’ingénierie modernes
Parcours utilisateurs et maquettes :
• Suivant les progiciels l’intégration d’un UX Designer dans l’équipe est plus ou moins
pertinente
• Organisation de tests utilisateurs
Attention particulière prêtées aux tests :
• Validation d’une application construite en mode itératif et incrémental
• Rejeu régulier des tests de non régression tout au long de la phase de réalisation

47. Nos apprentissages
✓ Partage de la vision
✓ Immersions terrains en équipe
complète et ateliers avec les utilisateurs
pour générer compréhension et
empathie
✓ Colocalisation des membres de l’équipe
✓ Implication des utilisateurs finaux
• Challenger les besoins pour limiter les
développements spécifiques au
maximum, surtout dans le cas de la
refonte d’un outil
• Esprit « one team » & forfait
• Mise en place de pratiques de test
efficaces
Ce qui marche Ce qui reste compliqué

48. Réalisation

49. Objectifs de la phase
Développer la meilleure solution possible en réponse aux besoins et
en respectant les contraintes en collaboration étroite avec le
titulaire.
Sécuriser la réalisation en s’appuyant sur des validations et des
feedbacks réguliers
Mettre en œuvre une gestion des risques au plus près du quotidien
de l’équipe

50. Affinage du besoin
Affinage progressif du besoin en mode collaboratif :
• Priorisation travaillée par le duo PO/PPO
• Maintien à jour du backlog et de la story map
• Découpage des fonctionnalités en « user stories » en collaboration avec le
titulaire
• Si le besoin exprimé nécessite des développements spécifiques :
challenger férocement le besoin et/ou la solution envisagée
• Prise en compte des retours utilisateurs pour mise à jour éventuelle du
backlog et/ou de la roadmap

51. Organisation de la réalisation
Réalisation en mode itératif et incrémental
• Identifier la bonne durée d’itération
• Respect des priorités partagées par le PO / PPO
Validation progressive des développements réalisés :
• Mise à disposition très rapidement d’un environnement de recette
distinct de l’environnement de développement
• Tests réalisés le plus possible au fil de l’eau (via des tests d’acceptation
tirés des US par exemple). Ne pas attendre que l’ensemble d’une
fonctionnalité soit développée pour commencer à la tester !
• Mise en place pragmatique de tests automatisés
• Organisation de démonstrations spécifiques à destination des parties
prenantes et des utilisateurs finaux

52. Pilotage
Mise en place et exploitation des indicateurs agiles classiques
• Vulgarisation de ces indicateurs auprès de l’équipe et des parties
prenantes
• Avancement de la réalisation communiquée de façon parlante
aux Métiers et représentants des utilisateurs (via la Story Map par
ex.)
• Organisation de démonstrations comme preuve de
l’avancement

53. Nos apprentissages
✓ Affinage progressif du besoin en
collaboration étroite avec le titulaire
✓ Organisation de démonstrations
comme preuve d’avancement
✓ Continuer à impliquer des utilisateurs
finaux dans la phase de réalisation
✓ Sécurisation via validation progressive
tout au long de la réalisation
• Niveau de discipline requis à tous les
niveaux (limitation des développements
spécifiques, tests au fil de l’eau, etc.)
• Equilibre à trouver concernant
l’intégration des feedbacks et des
évolutions du besoin dans un cadre
forfaitaire
• Maintenir un niveau élevé de
transparence dans un cadre forfaitaire
Ce qui marche Ce qui reste compliqué

54. Capitalisation

55. Apprendre de nos expériences
Mise en œuvre de l’amélioration continue sur les projets en
impliquant l’équipe RATP comme l’équipe du titulaire.
Partage des REX projets :
• Systématisation en cours
• Partage plus ou moins « grand public interne »
Capitalisation au niveau des coachs :
• Echange et entraide entre coachs
• REX des équipes accompagnées par les coachs inscrits dans les
contrats de coaching
• Mise à jour du Mémento Projet animée par les coachs

56. Si vous ne deviez retenir qu’un
slide …

57. Nos principaux apprentissages
• Ne lésinez pas sur l’accompagnement de vos Métiers, vos équipes et vos fournisseurs
• Vulgarisez l’Agilité auprès de tous les acteurs :
• Attention au vocabulaire utilisé
• Revenez aux fondamentaux de l’agilité
• Clarifiez vos intentions, donnez du sens à vos demandes
• La gestion de risques est un bon axe de vulgarisation de l’agilité
• Expérimentez :
• Sur différents projets
• Au sein du même projet (amélioration continue)
• Soyez humble : apprenez de ce qui marche et de ce qui ne marche pas aussi bien que
prévu …

58. Posez vos
questions !

60. Merci pour vos
retours !