Le retour d'expérience du mois
L’architecture doit passer d’une posture de gouvernance à une posture d’influenceIbrahima NDIAYE, CTO de la Digital Factory - RATP
Retour
Ibrahima NDIAYE a acquis une expérience d’une vingtaine d’années dans le domaine de l’architecture d’entreprise. Il rejoint la RATP en 2023 comme Architecte d’Entreprise, puis est nommé CTO de la Digital Factory en 2025. Lors de la matinale organisée par le CRiP le 5 mai, Il a présenté une vision revisitée du rôle de l’Architecture d’Entreprise et des architectes qui doivent changer totalement de posture, abandonner la tour d’ivoire qui les isole du business, et certaines structures, et devenir des facilitateurs dans la prise de décision du DSI et dans l’aide à ses équipes.
Pour être provocant, l’animateur a déclaré que notre job d’architecte était de contribuer à la réussite professionnelle du DSI. Et en y réfléchissant, cette définition n’était pas aussi décalée que cela.
Pour moi, mon rôle d’architecte ne se limite pas à décliner une méthodologie, ou d’appliquer ce que TOGAF m’a appris. Les bonnes questions à se poser sont plutôt : « Est-ce que mon entreprise doit améliorer son expérience client ? », « Est-ce que je dois accélérer la cadence de livraison des projets » ; « Est-ce que je dois simplement gérer du risque et de la conformité ? » ou encore « Est-ce que dois adopter de nouvelles technologies comme l’IA, la blockchain etc… »
Apres avoir rejoint la RATP comme Architecte d’Entreprise, on m’a confié le rôle de CTO de la Fabrique Digitale, Modestement, je considère que mon rôle consiste à éveiller les consciences de mes équipes sur ces sujets qui tournent autour du futur de l’Architecture d’Entreprise et Solution et la posture de l’Architecte d’Entreprise et Solution, et de le faire en étroite collaboration avec le DSI pour accorder mes actions à ses priorités business.
Ces architectes sont principalement répartis à la DSI (57), dans les filiales (20), au siège (11). La Digital Factory est en quelque sorte la branche IT de la RATP qui inclut le développement et intégration.
A la RATP, comme dans beaucoup d'autres grandes entreprises, l'architecture d'entreprise a longtemps souffert d'une mauvaise image. Certains s'interrogeaient sur l'utilité même d'une cellule d'architecture. Cette perception venait d'une mauvaise compréhension de la vraie fonction de l'architecte, avec son lot de clichés : des gens dans une tour d'ivoire, rédigeant des documents abstraits lus par une poignée d'experts, parfois éloignés des réalités opérationnelles.
Depuis environ trois ans, sous l'impulsion de Laurent Boutal, notre Chief Architect, cette image change. Une véritable dynamique d'architecture s'est installée à l'échelle de l'entreprise. Tout n'est pas parfait, mais les bases sont solides et les compétences sont là.
Depuis peu, l'arrivée de l'IA remet en question le rôle de l'architecte d'entreprise. On navigue entre des fournisseurs qui nous expliquent que l'IA va tout générer seule, un schéma directeur, une instruction d'architecture, et d'autres qui proposent l'IA pour « augmenter » les architectes existants. Mais le vrai enjeu n'est pas là. Avec l'IA, et surtout avec l'arrivée d'agents, une partie croissante des décisions, business comme IT, va se prendre de façon automatisée, parfois sans qu'on les voie passer. La question devient alors : qui décide, sur quelle base, et comment trace-t-on ces décisions ?
C'est précisément là que l'architecte reprend tout son sens. Sa valeur ne réside plus dans la production de normes, mais dans sa capacité à éclairer la décision : formuler les alternatives, expliciter les conséquences et les compromis, rendre la décision lisible et traçable.
La survie de l'Architecture d'Entreprise passe donc par une remise en question profonde : l'architecture doit passer d'une posture de gouvernance à une posture d'influence. Les architectes ne doivent plus être perçus comme des juges de paix ou des théoriciens de la normalisation. Ils doivent se mettre au service de la mission du DSI et du CTO, les accompagner dans l'atteinte de leurs objectifs business, tout en installant les bonnes pratiques pour l'entreprise. Leur rôle bascule du contrôle vers l'aide à la décision.
Nous commençons par positionner les différents projets du DSI sur un diagramme simple. En abscisse, nous identifions la temporalité (court terme, moyen terme et long terme). Et en ordonnée, nous évaluons des projets selon un axe allant du statut de projet très tactique à projet très stratégique.
De manière générale, les dossiers à long terme traiteront en majorité de vision et de stratégie. De même, on retrouvera dans la catégorie ‘moyen terme’ ceux qui seront plutôt orientés autour de fondations et de plateformes. Et les projets à court terme seront généralement des projets tactiques, et dans ce cas, l’objectif du DSI est de mener à bien et d’exécuter rapidement ces projets.
Une discussion s’instaure ensuite avec le DSI et le CTO pour le faire un choix de focus entre ces extrêmes, car on ne peut pas travailler sur tout en même temps.
Dans mon rôle de CTO de la Fabrique Digitale, cela voulait dire une chose : on n'attendait pas de moi de grands schémas directeurs, lourds et longs à produire, qui finissent rarement lus et rarement suivis. Ce qu'on attendait, c'était de l'impact sur les projets. Et pour avoir de l'impact, il ne faut pas une architecture parfaite, il faut une architecture utile : des schémas simples, des alternatives clairement posées, des compromis assumés.
Face à une situation complexe, le schéma doit rester simple. C'est ce qui permet à l'IT comme aux métiers de comprendre, de discuter et de décider ensemble.
Au fond, ce qu'il nous fallait, ce n'était pas plus de gouvernance. C'était une organisation conçue pour aider à la décision.
L’équipe Projets et Produits rassemble des architectes solution qui aident les projets et les produits à construire des instructions d’architecture en amont des projets, et à prendre la bonne orientation. Nous avons instauré des revues de solutions, que l’on a nommées « Solution Boards », de façon éviter des termes un peu sclérosants, comme que comité d’architecture. Les architectes sont solidaires des équipes projets, ils les assistent dans les choix technologiques. Une fois ces solutions débattues par le Solution Board, nous les entérinons dans des Architecture Decision Records, qui serviront notamment pour la traçabilité ultérieure des projets.
De l’autre côté, dans le pan Evolutions Technologiques, nous agissons pour faire évoluer les socles qui permettront d’accélérer la livraison des projets... Nous avons créé une instance CTO Office qui nous permet de discuter avec les responsables des socles sur les besoins des projets et comment faire évoluer leurs offres. On y parle de standards, de patterns ou encore de capability maps.
Cette organisation en deux volets, simple à comprendre, nous permet de converger vers de l’aide à la prise de décision.
Enfin, nous avons mis en place une démarche autour d’un livrable et d’un template, qui sont partagés lors d’une seule revue de solution et historisés vers les ADR pour assurer la traçabilité.
Dans ce livrable, nous sommes sur du High Level Design, destiné à exprimer l’intentionnel de l’architecture, en n’imposant volontairement aucun outil particulier. On s’est rendus compte qu’avec cette façon de simplifier les livrables et les schémas, on retrouvait du dialogue et de la compréhension au travers des équipes Métiers et IT.
Qu’est-ce qui fait de vous un visionnaire de l’Architecture d’Entreprise ?
Lors d’un événement organisé par le Gartner® il y a quelques années, l’animateur avait demandé aux participants quelle était selon eux la vraie mission de l’Architecte d’Entreprise. Parmi les réponses, on trouvait par exemple : « aligner la stratégie métier avec l’évolution technologique », « définir l’évolution du patrimoine applicatif et technologique », « assurer le respect des standards et de la gouvernance », ou encore « piloter la transformation numérique à travers des principes et des règles ».Pour être provocant, l’animateur a déclaré que notre job d’architecte était de contribuer à la réussite professionnelle du DSI. Et en y réfléchissant, cette définition n’était pas aussi décalée que cela.
Pour moi, mon rôle d’architecte ne se limite pas à décliner une méthodologie, ou d’appliquer ce que TOGAF m’a appris. Les bonnes questions à se poser sont plutôt : « Est-ce que mon entreprise doit améliorer son expérience client ? », « Est-ce que je dois accélérer la cadence de livraison des projets » ; « Est-ce que je dois simplement gérer du risque et de la conformité ? » ou encore « Est-ce que dois adopter de nouvelles technologies comme l’IA, la blockchain etc… »
Apres avoir rejoint la RATP comme Architecte d’Entreprise, on m’a confié le rôle de CTO de la Fabrique Digitale, Modestement, je considère que mon rôle consiste à éveiller les consciences de mes équipes sur ces sujets qui tournent autour du futur de l’Architecture d’Entreprise et Solution et la posture de l’Architecte d’Entreprise et Solution, et de le faire en étroite collaboration avec le DSI pour accorder mes actions à ses priorités business.
Comment l’Architecture d’Entreprise est-elle structurée à la RATP ?
Aujourd’hui, la RATP réunit plus de 73 500 collaborateurs dans le monde, dont 25% travaillent à l’international. Pour ce qui concerne l’Architecture d’Entreprise, elle repose sur une centaine de personnes avec plusieurs profils : des architectes techniques, des architectes systèmes, des architectes SI et solutions, des architectes systèmes pour les aspects plus industriels, des architectes Cyber, data, logiciels.Ces architectes sont principalement répartis à la DSI (57), dans les filiales (20), au siège (11). La Digital Factory est en quelque sorte la branche IT de la RATP qui inclut le développement et intégration.
A la RATP, comme dans beaucoup d'autres grandes entreprises, l'architecture d'entreprise a longtemps souffert d'une mauvaise image. Certains s'interrogeaient sur l'utilité même d'une cellule d'architecture. Cette perception venait d'une mauvaise compréhension de la vraie fonction de l'architecte, avec son lot de clichés : des gens dans une tour d'ivoire, rédigeant des documents abstraits lus par une poignée d'experts, parfois éloignés des réalités opérationnelles.
Depuis environ trois ans, sous l'impulsion de Laurent Boutal, notre Chief Architect, cette image change. Une véritable dynamique d'architecture s'est installée à l'échelle de l'entreprise. Tout n'est pas parfait, mais les bases sont solides et les compétences sont là.
Qu’est-ce qui a impulsé la « révolution architecturale » que vous avez conduite à la RATP ?
Pour moi, le vrai souci aujourd’hui est que la prise de décision IT est de plus en plus difficile. On a de plus en plus de mal à savoir, notamment dans des grandes entreprises comme la nôtre, qui prend la décision, où la prend-on, et comment est-elle tracée. Et le fait que notre environnement technologique soit en pleine accélération et devienne de plus en plus complexe, ne fait qu’aggraver ce phénomène.Depuis peu, l'arrivée de l'IA remet en question le rôle de l'architecte d'entreprise. On navigue entre des fournisseurs qui nous expliquent que l'IA va tout générer seule, un schéma directeur, une instruction d'architecture, et d'autres qui proposent l'IA pour « augmenter » les architectes existants. Mais le vrai enjeu n'est pas là. Avec l'IA, et surtout avec l'arrivée d'agents, une partie croissante des décisions, business comme IT, va se prendre de façon automatisée, parfois sans qu'on les voie passer. La question devient alors : qui décide, sur quelle base, et comment trace-t-on ces décisions ?
C'est précisément là que l'architecte reprend tout son sens. Sa valeur ne réside plus dans la production de normes, mais dans sa capacité à éclairer la décision : formuler les alternatives, expliciter les conséquences et les compromis, rendre la décision lisible et traçable.
La survie de l'Architecture d'Entreprise passe donc par une remise en question profonde : l'architecture doit passer d'une posture de gouvernance à une posture d'influence. Les architectes ne doivent plus être perçus comme des juges de paix ou des théoriciens de la normalisation. Ils doivent se mettre au service de la mission du DSI et du CTO, les accompagner dans l'atteinte de leurs objectifs business, tout en installant les bonnes pratiques pour l'entreprise. Leur rôle bascule du contrôle vers l'aide à la décision.
Par quoi commencer ?
La première chose à faire est de mieux comprendre les objectifs du DSI et du CTO, de façon à adapter les chantiers d’Architecture d’Entreprise en fonction de leurs priorités.Nous commençons par positionner les différents projets du DSI sur un diagramme simple. En abscisse, nous identifions la temporalité (court terme, moyen terme et long terme). Et en ordonnée, nous évaluons des projets selon un axe allant du statut de projet très tactique à projet très stratégique.
De manière générale, les dossiers à long terme traiteront en majorité de vision et de stratégie. De même, on retrouvera dans la catégorie ‘moyen terme’ ceux qui seront plutôt orientés autour de fondations et de plateformes. Et les projets à court terme seront généralement des projets tactiques, et dans ce cas, l’objectif du DSI est de mener à bien et d’exécuter rapidement ces projets.
Une discussion s’instaure ensuite avec le DSI et le CTO pour le faire un choix de focus entre ces extrêmes, car on ne peut pas travailler sur tout en même temps.
Comment avez-vous opéré cette étape avec votre DSI ?
Quand j’ai discuté avec mon DSI de ce qui était le plus important pour lui, c’était de délivrer des projets pour les métiers. Nos premiers clients ce sont les agents RATP qui servent nos usagers. Nous devons fabriquer de nouveaux outils pour nos agents, et délivrer rapidement des produits de très bonne qualité. On pourrait dire qu’à la RATP, aujourd’hui notre focus est plutôt sur les projets et leur exécution, avec peut-être un léger débordement induit sur les plateformes, mais nous n’avons pas de planning spécifique sur des transformations stratégiques.Dans mon rôle de CTO de la Fabrique Digitale, cela voulait dire une chose : on n'attendait pas de moi de grands schémas directeurs, lourds et longs à produire, qui finissent rarement lus et rarement suivis. Ce qu'on attendait, c'était de l'impact sur les projets. Et pour avoir de l'impact, il ne faut pas une architecture parfaite, il faut une architecture utile : des schémas simples, des alternatives clairement posées, des compromis assumés.
Face à une situation complexe, le schéma doit rester simple. C'est ce qui permet à l'IT comme aux métiers de comprendre, de discuter et de décider ensemble.
Au fond, ce qu'il nous fallait, ce n'était pas plus de gouvernance. C'était une organisation conçue pour aider à la décision.
Comment avez-vous mis l’organisation en mouvement ?
Pour faire ceci il y a quelques principes à respecter :- En tant qu’Architecte d’Entreprise, il faut formuler et prioriser l’ambition à partir du diagramme des projets revu avec le DSI et le CTO. Cela fait partie des vraies choses que l’on doit rédiger, il faut identifier des indicateurs clés et mapper l’effort nécessaire pour atteindre nos objectifs.
- Il faut ensuite rendre l’architecture utilisable ou actionnable. Il faut pour cela simplifier le message et rendre la visualisation compréhensible par tous, de l’IT aux Métiers et jusqu’au Management. Pour avoir des architectures actionnables il faut qu’elles soient flexibles, adaptables et composables. Il faut éviter l’écueil d’une architecture trop rigide. On doit pouvoir adapter un schéma architectural sans devoir tout casser.
- Ces 2 premières phases une fois réalisées, il faut modéliser la décision. Si jusqu’à présent, on avait passé notre temps à modéliser des processus, de l’architecture, et il est temps maintenant de modéliser la décision. Et cette phase prend une importance particulière en raison de la mise en place progressive de l’IA, avec l’arrivée d’agents qui va nous nous aider dans la décision (pas seulement la décision business, mais de plus en plus la décision IT). Cela veut dire qu’il faut mettre en exergue les alternatives et les différentes options, tracer ces alternatives de décisions et mettre le tout en perspective dans une trajectoire. On trouve pas mal de références du Carnegie Institute sur l’ingénierie de la décision.
- Pour terminer, et c’est sans doute le plus important pour moi, les architectes doivent changer de posture, arrêter d’avoir cette image de comitologue, de contrôleur et de juge ultime de la beauté d’une architecture. Nous devons évoluer vers une posture d’accompagnement et de facilitateur dans la prise de décision et dans l’aide aux équipes. Loin des compétences théoriques, c’est de soft skills qui sont de plus en plus nécessaires chez les Architectes.
Dans les faits, comment avez-vous facilité l’aide à la décision ?
En termes d’organisation, pour faciliter la prise de décision, nous avons mis en place deux démarches équipes : une qui est focalisée sur les projets et produits, et l’autre sur les Evolutions Technologiques.L’équipe Projets et Produits rassemble des architectes solution qui aident les projets et les produits à construire des instructions d’architecture en amont des projets, et à prendre la bonne orientation. Nous avons instauré des revues de solutions, que l’on a nommées « Solution Boards », de façon éviter des termes un peu sclérosants, comme que comité d’architecture. Les architectes sont solidaires des équipes projets, ils les assistent dans les choix technologiques. Une fois ces solutions débattues par le Solution Board, nous les entérinons dans des Architecture Decision Records, qui serviront notamment pour la traçabilité ultérieure des projets.
De l’autre côté, dans le pan Evolutions Technologiques, nous agissons pour faire évoluer les socles qui permettront d’accélérer la livraison des projets... Nous avons créé une instance CTO Office qui nous permet de discuter avec les responsables des socles sur les besoins des projets et comment faire évoluer leurs offres. On y parle de standards, de patterns ou encore de capability maps.
Cette organisation en deux volets, simple à comprendre, nous permet de converger vers de l’aide à la prise de décision.
Enfin, nous avons mis en place une démarche autour d’un livrable et d’un template, qui sont partagés lors d’une seule revue de solution et historisés vers les ADR pour assurer la traçabilité.
Dans ce livrable, nous sommes sur du High Level Design, destiné à exprimer l’intentionnel de l’architecture, en n’imposant volontairement aucun outil particulier. On s’est rendus compte qu’avec cette façon de simplifier les livrables et les schémas, on retrouvait du dialogue et de la compréhension au travers des équipes Métiers et IT.
Au final, quels sont vos conseils pour insuffler une nouvelle posture à l’Archiceture d’Entreprise ?
J’en vois quatre principaux :- Déterminer le focus réel de l’AE, comprendre comment elle peut contribuer concrètement à la réalisation des objectifs de l’entreprise,
- Simplifier ses messages, sortir de sa tour d’ivoire,
- Délaisser la posture de gouvernance pour aller vers l’influence, devenir des contributeurs au succès d’une équipe, plutôt que de rester des arbitres de la méthodologie,
- Intégrer de plus en plus l’architecture au sein des équipes IT, former progressivement les techniciens et les développeurs aux réflexions architecturales.
Autres articles sur le même thème
Retour d'expérience du mois
Créer une application LC/NC pour nos techniciens en intervention Field Service
Par Julien Desgoutte
Par Julien Desgoutte
Mag #34
Lire l'article
Retour d'expérience du mois
Réduire le nombre d’alertes pour améliorer l’efficacité opérationnelle
Vladimir Kharlamoff d'AGIRC-ARRCO
Vladimir Kharlamoff d'AGIRC-ARRCO
Mag #33
Lire l'article
