Étude de cas : ADEO / Référentiel de flux
Le contexte : un SI fait d'échanges
ADEO est un groupe international de l'amélioration de l'habitat, organisé en entreprises et en business units qui disposent chacune de leur propre système d'information. Pour que ces applications communiquent, le groupe s'appuie sur un bus d'intégration (ESB) qui reçoit, transforme et achemine les données.
Avec de nombreux échanges, une question devient centrale pour les architectes et les équipes projet : si je modifie cette application, qui est impacté ?
Le rôle du référentiel
Le référentiel de flux recense les échanges entre applications : il permet de les retrouver, de les visualiser et d'analyser l'impact d'une évolution.
Ce qu'est le référentiel de flux
- Un outil d'analyse d'impact sur le système d'information, utilisé principalement par les architectes SOA et les chefs de projet.
- Alimenté automatiquement par les outils d'échange (bus d'intégration, passerelle de fichiers, gestion des API, streaming de données), et complété manuellement pour les autres technologies.
- Une application qui ne stocke pas les données des flux elles-mêmes, mais leurs modèles et des exemples, pour construire une cartographie ajustable.
Objectif du produit Devenir le référentiel unique des échanges du groupe. Il s'agit d'un objectif formulé pour le produit, pas d'un résultat présenté ici comme atteint.
Les notions à maîtriser : flux, demi-flux, format canonique, environnements
format natifcanoniqueformat natif- Intégration
- Recette
- Préproduction
- Production
Schéma pédagogique recréé : le principe des demi-flux et des environnements successifs.
- Flux
- Une liaison à sens unique : un flux de A vers B permet à A d'agir sur B.
- Demi-flux
- Chaque flux est découpé en deux parties indépendantes : FROM, de l'application productrice vers le format pivot, et TO, du pivot vers l'application consommatrice.
- Format canonique
- Une structure de données commune, indépendante des applications, interne au bus d'intégration.
- Environnements
- Intégration, recette, préproduction et production : chacun valide le flux d'un point de vue différent avant le suivant.
Mon rôle : du terrain au Product Ownership
- Octobre 2022 Arrivée chez Fabrick : prise de poste en architecture SOA, dans l'équipe qui accompagne les échanges d'ADEO.
- Trois mois Traitement de demandes de flux, avec le référentiel comme outil de référence.
- Janvier 2023 J'intègre l'équipe produit du référentiel comme assistant du Product Owner.
- Janvier 2024 Fin de l'alternance.
Prise de poste — trois mois en architecture SOA
Je traitais des tickets de création, de modification ou de suppression de demi-flux, soumis par des équipes projet de plusieurs pays. Chaque ticket fonctionnait comme un petit projet :
- Lire la spécification
- Vérifier la faisabilité
- Échanger avec l'équipe projet
- Traduire le besoin pour les équipes qui réalisent et déploient
Trois mois à traiter des demandes de flux m'ont fait connaître le produit et ses utilisateurs avant de rejoindre son équipe.
Assistant Product Owner — rejoindre l'équipe produit
J'utilisais le référentiel chaque jour. En échangeant avec un collègue, j'ai compris qu'un projet d'évolution était en cours ; l'occasion s'est présentée d'assister le Product Owner.
Un atout de départ
Je connaissais déjà le produit comme utilisateur : son vocabulaire, ses usages et ses limites. J'ai abordé ses évolutions avec une compréhension concrète du besoin.
Se mettre à niveau sur un produit de six ans
- Le vocabulaire métier : flux, demi-flux, format canonique, environnements.
- Les normes et référentiels en usage : ISO 9001 (qualité), ISO 27001 (sécurité de l'information), ITIL (gestion des services informatiques), RGPD, charte graphique.
- La réglementation : l'application stocke peu de données, mais certaines sont personnelles (les contacts associés aux flux).
- L'existant : à la création du référentiel de flux, aucun outil équivalent ; des solutions génériques permettent aujourd'hui de cartographier des flux, mais le référentiel reste adapté aux usages précis de ses utilisateurs.
Comprendre les utilisateurs
Parmi les idées que j'ai apportées : interroger directement les utilisateurs, pour cerner leur façon de travailler et ce dont ils ont réellement besoin, plutôt que de partir des seules demandes d'évolution.
Extrait d'entretien avec un architecte SOA
- Quel est votre quotidien sur le référentiel de flux ?
- Pour une création de demi-flux, il crée le flux dans le référentiel, renseigne chaque champ (documentation, nom du demi-flux, business unit concernée), informe le contact principal, ajoute le connecteur, puis transmet le ticket à l'équipe suivante.
- Qu'attendez-vous des prochaines versions ?
- Des recherches plus strictes pour éviter les résultats trop nombreux, une recherche mieux optimisée, et un nouvel écran d'accueil.
Ce que les entretiens ont fait ressortir
-
Un processus
Les étapes réelles de création d'un flux, qui éclairent l'architecture métier.
-
Un irritant
La recherche renvoie trop de résultats pour retrouver rapidement le bon flux.
-
Une attente
Un écran d'accueil plus clair.
Enseignement Le besoin exprimé (« plus de filtres ») cache un besoin réel : retrouver le bon flux sans perdre de temps. C'est ce second besoin qui guide la solution.
Proposition Avec le recul : des personas et des parcours utilisateurs auraient permis de mieux comprendre le métier de chaque profil.
Du besoin au backlog
- Entretien
- Processus modélisé
- User stories
- Story map
- Backlog
Les user stories
-
En tant qu'architecte SOA,
je souhaite pouvoir effectuer des recherches plus strictes (filtres)
afin de gagner du temps.
-
En tant qu'architecte SOA,
je souhaite une meilleure optimisation de la recherche
afin de ne plus obtenir plusieurs résultats au lieu d'un seul.
Formulations légèrement adaptées pour la lecture.
Le story mapping dans Jira
J'ai organisé les besoins en story map : les epics en haut, les user stories en dessous, chacune découpée en tâches. Cette vue a servi de base à la planification des sprints.
EpicRechercher un flux
-
User storyFiltrer pour une recherche stricte
- Définir les filtres utiles
- Adapter l'interface de recherche
- Recetter avec des utilisateurs
-
User storyObtenir le bon résultat
- Analyser les résultats actuels
- Améliorer la pertinence
- Valider sur des cas réels
EpicAccueil de l'application
-
User storyRefondre l'écran d'accueil
- Recueillir les attentes
- Valider la maquette
- Recetter
Une proposition intégrée au backlog : la protection des données
En étudiant la réglementation applicable, j'ai constaté que les noms des contacts associés aux flux étaient stockés en clair. J'ai proposé de chiffrer au minimum ces données ; la proposition a été ajoutée au backlog du sprint suivant.
Scrum en pratique
L'équipe du référentiel travaillait en Scrum : deux développeurs full stack et un Product Owner, qui assurait aussi le rôle de Scrum Master. J'ai pu observer et pratiquer le cadre que j'avais étudié en formation.
-
Product Backlog
Story mapping : epics, user stories, tâches
-
Sprint Planning
Animé ponctuellement, avec estimation en tailles de vêtements
-
Sprint Backlog
Constitué lors de la planification
-
Sprint
Avancement suivi par un burndown chart
-
Rétrospective
Format KISS ; Speed Boat proposé
Proposition -
Feedback
Avis dans l'application et notation
Animer un Sprint Planning
J'ai animé exceptionnellement une réunion de planification. Je connaissais encore peu l'équipe : j'ai ouvert la séance par un brise-glace (« Quel est votre animal préféré, et pourquoi ? »), puis proposé un planning poker en tailles de vêtements plutôt qu'en points.
- S
- Facile
- M
- Un peu difficile
- L
- Difficile
- XL
- Très difficile
L'estimation s'est déroulée rapidement, et l'échelle a été bien reçue. Avec deux développeurs qui se connaissaient depuis longtemps, la dynamique d'équipe a aussi beaucoup joué.
Suivre l'avancement : le burndown chart
Avec les données récupérées pendant le sprint, j'ai mis en place un burndown chart pour visualiser le travail restant par rapport à une progression idéale.
- Progression idéale
- Travail restant (points)
- Données fictives
Rétrospective et pistes d'amélioration
Constat L'équipe utilisait le format KISS (Keep, Improve, Start, Stop) pour ses rétrospectives.
Proposition Essayer le Speed Boat, une rétrospective plus visuelle et ludique.
Proposition Estimer avec la suite de Fibonacci et travailler explicitement le MVP, plus parlant pour tous.
Proposition À terme, confier le rôle de Scrum Master à une autre personne pour dégager du temps au Product Owner.
Piloter : risques, gouvernance, changement
Au-delà du backlog, j'ai travaillé sur les dimensions de pilotage du projet. Une partie de ce travail relève de l'exercice, dans le cadre de mon mémoire : chaque élément est qualifié ci-dessous.
Gestion des risques Exercice de mémoire
Exercice de mémoire Analyse et plan d'action réalisés dans mon mémoire. Je n'avais pas de visibilité sur les plans d'action d'ADEO, et aucune des mesures proposées n'a été mise en œuvre par moi.
J'ai identifié des risques de plusieurs natures (humains, stratégiques, financiers, organisationnels, politiques, de qualité, techniques), puis évalué leur sévérité : gravité × probabilité. Exemple étudié : la dépendance au réseau d'une application hébergée dans le cloud, rare mais majeure.
| Très forte | Dépendance au réseau : probabilité faible, gravité très forte | ||||
|---|---|---|---|---|---|
| Forte | |||||
| Moyenne | |||||
| Faible | |||||
| Très faible | |||||
| Très faible | Faible | Moyenne | Forte | Très forte |
- Deux fournisseurs d'accès à Internet
- Routeurs 4G de secours
- Fibre dédiée avec garantie de temps de rétablissement de 4 heures
- Bascule des équipes en télétravail
Avec le recul Une matrice visuelle aurait été plus lisible que le tableau utilisé.
Gouvernance : clarifier les responsabilités
À mon arrivée, il était difficile de savoir qui informer et qui consulter. J'ai mis en place une matrice RACI pour identifier clairement les acteurs clés du projet et leur rôle.
| Activité | Product Owner | Développeurs | Utilisateurs clés | Assistant PO |
|---|---|---|---|---|
| Prioriser le backlog | A | C | C | R |
| Réaliser une évolution | A | R | I | C |
| Valider en recette | A | C | R | R |
| Informer les utilisateurs | A | I | I | R |
Accompagner le changement
Pour que les utilisateurs comprennent et adoptent les évolutions, j'ai suivi les étapes de la méthode de Kotter.
-
Phase 1
Impulser
- Matrice des parties prenantes
-
Phase 2
Développer les capacités
- Atelier avec cinq architectes SOA, structuré par le questionnement CQQCOQP
-
Phase 3
Transformer
- Plan de communication Préparé
- Plan de formation des utilisateurs Préparé
- Quick wins Préparé
-
Phase 4
Consolider
- Sondages pour recueillir les retours Proposition
Retours utilisateurs Avec le Product Owner, nous avons permis de donner son avis directement dans le référentiel et de noter l'application.
Proposition Un questionnaire plus visible, et des outils complémentaires : matrice d'impact, matrice d'engagement.
Ressources et organisation
- Plan de charge
- Peu adapté à une équipe agile, qui ajuste ses besoins au fil des sprints ; il garde son intérêt pour un engagement au forfait.
- Ressources financières
- Sans accès aux données financières, j'ai construit un exemple de pilotage par lots de tâches et d'estimation en jours-homme.
- Triangle d'or
- Je voulais piloter avec le triangle coût, délai, qualité ; le projet n'avait en réalité pas de contrainte forte de délai ni de coût visible à mon niveau. J'ai tout de même suivi les phases d'un projet classique au sein du cadre Scrum.
Exercice de mémoire L'estimation par lots et le calcul de ressources sont des exercices du mémoire, avec des valeurs d'exemple.
Réflexions d'architecture Exercice de mémoire
Exercice de mémoire Réflexions menées dans le cadre du mémoire. Je n'ai pas conçu l'architecture réelle du référentiel de flux.
- Expérience utilisateur
- Des experts UI/UX du groupe produisent des maquettes à partir d'un besoin, par exemple pour la refonte de la page d'accueil.
- Données
- Le référentiel s'alimente à partir d'API, de flux de données et d'exports d'autres applications, ce qui lui permet de suivre l'évolution des systèmes.
- Architecture logicielle
- Le référentiel est une application web unique ; j'ai imaginé une architecture projetée de ses évolutions possibles.
- Hébergement
- Comprendre le passage d'une infrastructure interne au cloud : ses avantages, ses inconvénients et les craintes qu'il suscite.
- Forces et faiblesses
- Une analyse SWOT, reprise régulièrement, pour situer le produit.
Qualité, recette et suivi
- Des indicateurs d'erreurs existaient déjà, ainsi qu'un outil d'analyse de la qualité du code intégré à la chaîne d'intégration.
- Un environnement de recette dédié précède toute mise en production.
- L'avancement se suit par le taux de réalisation de la feuille de route, l'intégration des données et les retours utilisateurs.
Ma part Je n'administrais pas ces outils. J'ai suivi l'avancement avec le burndown chart et, côté architecture SOA, participé à la rédaction d'un document de capitalisation pour les nouveaux arrivants.
Ce que cette expérience m'a apporté
- Une meilleure compréhension des systèmes d'information complexes et des dépendances entre applications.
- La différence entre un besoin exprimé et un besoin réel, et l'importance d'écouter les utilisateurs.
- La valeur d'une bonne communication entre métier et technique.
- La nécessité de prioriser, de suivre et d'améliorer en continu.
- Le passage d'une vision centrée sur le développement à une vision globale du projet.
Sortir du développement pur m'a obligé à sortir de ma zone de confort : aller vers les autres, comprendre leurs besoins, et décider en m'appuyant sur les données et sur l'équipe.
Compétences démontrées ici
- Coordination d'équipe et des interlocuteurs
- Analyse des risques
- Accompagnement au changement
- Recueil des besoins
- Entretiens et ateliers utilisateurs
- Analyse fonctionnelle
- Analyse d'impact
- User stories
- Gestion du backlog
- Story mapping
- Scrum
- Jira
- ESB et architecture SOA