IT Strat #3 - Une stratégie pour favoriser et maîtriser l'évolution organique de son SI

Après un article d’introduction sur l’IT Strat, qui présentait nos convictions et posait les principes d’une approche modernisée de la discipline, et un second volet sur la manière de prendre en compte les enjeux métier et technologiques dans la stratégie IT, nous allons voir dans ce 3eme épisode comment permettre un développement “organique” mais maîtrisé du SI, qui permet la croissance naturelle d'écosystèmes autonomes au sein de l’entreprise dans les différents domaines, en favorisant leur capacité d’adaptation dans le choix des solutions au contexte de chaque domaine.

La stratégie IT doit en effet s’appuyer sur une évolution du SI maîtrisée grâce à :

• une gestion rigoureuse et dynamique du patrimoine applicatif (Application Portfolio Management),
• des cartographies valorisées qui vont donner du sens à l’évolution du SI (en montrant l’existant et le chemin à prendre)
• un cadre directeur qui va fixer les grandes lignes du paysage souhaité (la cible intentionnelle) et les principes de son implémentation.
• une approche portfolio de la transformation, en particulier des enablers et des assets communs
• une capacité d’architecture d’entreprise pour éclairer les décisions en ayant une vision transverse

Gérer son patrimoine applicatif

Pour définir une stratégie éclairée, il est important d’avoir une vision claire et détaillée de son patrimoine applicatif existant. La méthode APM (Application Portfolio Management) va permettre de répertorier l'état des actifs du parc applicatif et de pouvoir objectiver les orientations budgétaires et choisir les actions à mener : investir dans des évolutions fonctionnelles de l’application ? rénover une partie des couches obsolètes ? réécrire son code pour atteindre une cible de qualité, de performance ou maintenabilité ? changer de solution pour mieux correspondre aux besoins métier ? décommissionner par absence d'usage ou doublon de couverture fonctionnelle ?

Cette classification va se baser sur plusieurs critères d’évaluation propres à chaque entreprise, mais on retrouve souvent les 3 critères principaux ci-dessous qui peuvent être chacun la synthèse de plusieurs éléments :

• Valeur métier : criticité, couverture fonctionnelle, efficacité & UX, évolutivité…
  Cet axe ne peut être évalué qu’avec le métier ou les responsables produit. Comme toute notation, elle peut être difficile au début dans l’absolu, mais en prenant des applications de référence qui font consensus (avec une valeur haute ou basse), il est ensuite plus facile d’évaluer les autres applications de manière relative. Des méthodes comme la “User Research” peuvent aider à formaliser le point de vue des utilisateurs.
• Valeur technique : architecture, obsolescence et gestion des versions, qualité logicielle, compétences et pérennité des fournisseurs…
  Souvent sujet à débat entre experts techniques, cette notation doit être la plus objective possible. Là aussi, l’échelle de notation est avant tout relative et la note d’une application dépendra du contexte de l’entreprise, de son avancement technologique, et surtout de l'existence (ou non) d'un cadre de cohérence technique.
• Coût de possession (TCO) : évaluation globale du Total Cost of Ownership, c’est-à-dire des coûts annuels récurrents (maintenance, déploiement, infrastructure, run associé, licences logicielles…).
  Sans doute le critère le plus difficile pour beaucoup d’entreprises qui ont du mal à évaluer les coûts par application, de la maintenance aux coûts de run, mais l’exercice est quand même utile pour nuancer la valeur technique avec l’estimation des efforts à mener pour opérer de manière récurrente une application et prioriser la transformation. Une application dite “legacy” avec une valeur technique médiocre mais avec un TCO faible sera moins prioritaire dans la transformation. A l’inverse une application moderne mais trop complexe à gérer mérite sans doute un ajustement de son architecture.

Exemple de cadran APM dans lequel les applications peuvent être positionnées selon leurs valeurs métier et techniques, et représentées avec des tailles différentes selon leur coût (TCO)

Dans ce type de démarche de qualification du patrimoine, les architectes peuvent jouer un rôle de facilitation et aider les équipes, mais cette vision doit idéalement être construite et mise à jour de manière continue par les équipes au plus proche des assets qui renseignent les différents critères. Cette approche bottom-up est facilitée par des outils comme LeanIX ou Backstage, un retour d’expérience intéressant d’Adrien Saunier et de Decathlon avait d’ailleurs été présenté à la Duck Conf 2024 sur l’automatisation dans la cartographie d’un SI en mouvement à partir des informations remontées par les équipes et les référentiels de code (1).

Une fois les applications positionnées dans le cadran APM, les décisions de transformation seront plus faciles à prendre régulièrement, avec plusieurs options :

• Continuité (keep) : valeurs métier et technique satisfaisantes. Cela ne signifie pas que tous ces assets ne doivent plus évoluer, d’autres critères seront à prendre en compte pour déterminer le niveau d’investissement requis pour rester dans cette partie du cadran
• Décommissionnement (remove) : valeurs métier et technique faibles ou application non adaptée au business model cible, sans possibilité de récupérer des briques techniques
• Evolution fonctionnelle (evolve) : socle technique suffisant pour capitaliser sur l’existant et augmenter la valeur métier de l’application (avec les investissements requis)
• Modernisation (modernize) qui peut se traduire par plusieurs options, les deux principales étant :
  • La reconstruction (replace / greenfield) : valeur métier élevée, mais dette technique trop importante qui implique une réécriture ou l’adoption d’une solution sur étagère ainsi qu'une stratégie de migration souvent complexe.
  • La rénovation (refactor / brownfield) : valeur métier satisfaisante, possibilité de modularisation et de réécriture partielle du code dans un objectif de baisse du TCO ou de migration vers le Cloud. L’approche brownfield peut paraître moins attirante qu’une réécriture complète, mais elle a des avantages à ne pas négliger en terme de ROI et dans une approche éco-responsable. La rénovation du code peut être associée à une approche de replatforming qui va porter sur la manière dont est exécutée l’application (cloud, conteneurisation)

Vous pourrez trouver plus de détails sur l’approche brownfield dans notre article de blog et le chapitre correspondant de notre publication Tech trends 2025 - OCTO Pulse (2). Attention toutefois à ne pas l’opposer de manière binaire brownfield et greenfield : une bonne stratégie de modernisation peut être de découper une application monolithique existante en sous-domaines à désimbriquer et à traiter différemment en greenfield ou brownfield selon leur dette technique, la complexité de rénovation et les ambitions métier.

Montrer l’évolution du SI

L’approche APM, ciblée sur l’existant, doit être confrontée avec la vision cible qui peut redécouper les frontières et remettre en question l’architecture existante. Cf notre épisode 2 - IT Strat qui aborde comment une approche Domain Driven Design permet d’avoir un découpage plus cohérent avec les objectifs du métier et de définir une stratégie de transformation avec l’aide d’outils comme le Core Domain Chart.
Le résultat visuel d’un APM ne permet pas de montrer aisément la transformation du SI, les applications y étant regroupées par cadran et non par domaine fonctionnel. Nous utilisons souvent en complément des cartographies valorisées pour montrer l’évolution du SI et donner du sens à la trajectoire.
Mapper le patrimoine applicatif existant avec les domaines fonctionnels, ou avec les domaines IT pour les communs technologiques, permet de visualiser l’utilité des actifs du SI. On peut ensuite y introduire un côté dynamique en montrant par exemple le lien avec la stratégie technologique (Cloud, Saas…) ou la stratégie de transformation en cible via des codes couleur (nouvelles applications, rénovation, décommissionnement…).

L’objectif est de mieux représenter les typologies d’applications, d’aider la prise de décision stratégique par les responsables, mais aussi d’aider les équipes à se projeter dans un mouvement global de transformation. Idéalement, tout comme l’APM, ce travail de mapping doit être partagé avec les équipes concernées et s’appuyer sur un outil qui permet un minimum d’automatisation. Les architectes peuvent aider les équipes en les accompagnant sur les décisions d’évolution, ils ont aussi la responsabilité de mettre en place le cadre technique (outils, référentiels) et de documenter la démarche en précisant les règles d'usage des outils.

Exemple de cartographie valorisée (zoom sur quelques domaines) qui montre les choix technologiques par application par l’utilisation de couleurs, les points de rénovation ou les études à mener par des pastilles

Formaliser un cadre directeur pour la transformation

A l’instar du paysagiste qui va poser un cadre propice au développement d’écosystèmes végétaux, la notion de cadre directeur est importante pour les équipes IT afin de donner de la visibilité, garantir la cohérence du SI et les aider à gagner en efficacité en évitant les indécisions et la multiplication des réunions d'arbitrage.
Un schéma directeur peut être nécessaire dans certains cas, mais un cadre directeur est moins rigide et détaillé, son ambition n’est pas d’avoir une roadmap exhaustive sur 3 ou 5 ans. Il doit être formalisé pour montrer l’intention, mais assez souple dans sa déclinaison pour être revu régulièrement, donner des orientations tout en laissant de l’autonomie aux équipes pour gérer le détail, s’adapter aux différents contextes et faire remonter les besoins d’ajustement du cadre directeur (boucle de feedback).

Le contenu d’un cadre directeur peut varier en profondeur, mais on y retrouve en général :

• Des principes directeurs pour le SI cible :
  • macro-découpage des domaines et mapping des applications principales : définition des responsabilités fonctionnelles et couverture des capacités métier. Cette vision d’ensemble structurée est indispensable pour que chacun puisse se projeter. Elle est idéalement issue de la convergence d’une vision de la direction et des équipes (approche bottom-up qui peut être favorisée par des pratiques comme le DDD abordé dans notre article précédent).
  • gouvernance de la donnée : quels objets métier sont manipulés et avec quelles responsabilités. L’exemple le plus fréquent est la donnée client / abonné partagée par plusieurs systèmes avec les questions de cohérence que cela implique.
  • principes d’urbanisation des échanges : description des modes de communication possibles dans le SI (synchrones, asynchrones) et préconisations selon les contraintes et les différents cas d’usage
  • orientations pour le découpage des services, principes d’exposition et de découplage pour rendre plus autonomes les déploiements et améliorer la résilience des systèmes

Exemple de principes directeurs sous forme de matrice entre les patterns d’échanges à disposition et les types problèmes rencontrés dans le SI

• Les grands choix technologiques structurants : Cloud providers et stratégie de déploiement (orientations IaaS, CaaS, PaaS, FaaS avec les principaux services à utiliser), technologies de Build et de Run à privilégier pour les applications customisées (du développement à la supervision), solutions SaaS sur étagère et modèles d’intégration…Toutes ces orientations doivent ensuite être déclinées et adaptées aux différents contextes dans une démarche agile.
• La description des patterns à privilégier : pour compléter les principes directeurs et éviter les malentendus sur l’implémentation, le cadre directeur peut donner plus de détails sur les modes de communications (API, messages / évènements…), les méthodes de sécurisation des applications et de la donnée, la manière d'implémenter des microservices, les solutions data (NoSQL, ODS…), l’observabilité, les modes de déploiement…
  On peut être tenté de dire que tous les patterns modernes d’architecture sont décrits sur Internet, mais l’expérience montre qu’il vaut mieux reformuler et partager les choses pour synthétiser l’essentiel, lever les malentendus et mieux évaluer l’utilisation de ces patterns dans le contexte de l’entreprise. Le temps passé en discussion et en indécisions dans les rituels ou les instances est en grande partie dû à une mauvaise appropriation des principes d’architecture, en particulier sur l’intégration et les échanges.

Une description rapide des patterns d’architecture (exemple ici orchestration vs chorégraphie),
avec leurs avantages, inconvénients et les principaux cas d’usage à privilégier, donne un support de discussion utile pour leur mise en oeuvre dans le SI

• Des modèles et des guidelines pour la mise en œuvre : blueprints d’architecture pour montrer l’articulation des différents patterns, les use cases, les réponses aux enjeux (cohérence, résilience, scalabilité…).
  Rentrer dans le détail des principaux cas d’usage dans l’entreprise (les plus importants et représentatifs) permet de rendre plus concrets les patterns d’architecture et de donner des exemples pertinents pour leur mise en œuvre. Ces modèles seront à affiner par les équipes produit qui devront prendre en compte toutes les contraintes et exigences.
• Les trajectoires : définition des étapes principales de transformation, description des scénarios possibles, des pré-requis, et des adhérences. Sans chercher à établir un planning détaillé voué à évoluer en permanence, il est important de montrer le chemin global vers la cible, et d’identifier les enablers nécessaires pour éviter les blocages dans la réalisation.

Exemple de trajectoire sur un écosystème de gestion des articles,
avec les grandes étapes de transformation

Avoir une approche portfolio des communs

La trajectoire IT doit être revue en continu et déclinée sous la forme d’un portefeuille d’initiatives qui intègre les projets métier mais aussi les enablers technologiques et les assets communs à mettre en place pour permettre la transformation du SI (gestionnaire d’identité, référentiels…). Ces communs sont à gérer sous trois angles pour passer à l’échelle :

• Dépendances : quelles applications et projets nécessitent ces communs ?
• Gouvernance : qui va développer et gérer ces communs ?
• Cycle de vie : quel statut pour ces communs et à quelles dates seront-ils disponibles ?

Ce schéma ci-dessous du cycle de vie technologique dans l’outil LeanIX (3) illustre bien les différents statuts possibles pour les assets communs : Plan (à l’étude), Phase in (build / en construction), Active (Run), Phase out (en cours de décommissionnement), End of life (décommissionné)

Illustration du cycle de vie des assets dans LeanIX,
les différents statuts sont corrélés avec la valeur et le risque associés

La principale difficulté à régler est de gérer un portfolio suffisamment complet pour avancer et impliquer les équipes, mais aussi suffisamment souple pour intégrer les besoins qui émergent au fur et à mesure, notamment les besoins de capacités transverses identifiées au fur et à mesure par les équipes. Celles-ci doivent optimiser leurs efforts et s’appuyer sur des enablers tout en restant les plus autonomes possible dans leur développement.
Pour trouver cet équilibre, il sera nécessaire de définir des priorités dans la construction des assets communs et d’estimer la valeur associée. Cette gestion du SI “as a product” est une tendance de plus en plus forte dans une intention de développement “organique”, inspirée du mode produit pour mesurer et apporter de la valeur, avec une repriorisation fréquente et une culture du feedback en coordination avec les différentes équipes qui fonctionnent dans un mode distribué.

Stratégie IT et Architecture d’Entreprise

Nous avons vu dans notre article précédent que la stratégie IT a pour objectif un alignement de la capacité IT avec la vision d’entreprise, avec l’outcome attendu par le métier. Et que pour y arriver, la stratégie IT devra aussi et surtout apporter du discernement : il faut du discernement sur les capacités de l’IT nécessaires pour supporter et développer les activités de l’entreprise, sur les choix technologiques, sur leur adéquation avec les besoins et contraintes métier.
Dans cet article, la notion de discernement a été approfondie en montrant l’importance de la maîtrise du patrimoine existant et de sa trajectoire d’évolution.

Pour apporter cet alignement et ce discernement, il faut créer un partenariat solide entre le métier et l’IT et penser l’architecture au niveau entreprise. Cette capacité d’architecture d’entreprise doit être portée soit par des ressources dédiées (les architectes d’entreprise), soit en distribuant ce rôle à une ou plusieurs personnes (responsables IT, CTO, architectes…). Nous reviendrons dans un autre article sur la nécessité d’une approche modernisée et organique de l’architecture d’entreprise. Ses objectifs seront les suivants :

• éclairer les décisions par rapport aux capacités de l'entreprise (courantes et en devenir), en ayant une vision transverse des volets technologiques, people, organisationnels et financiers;
• identifier les opportunités technologiques pour accomplir et enrichir la stratégie métier (boucle de feedback et innovation), tout en gérant le patrimoine existant (cycle de vie, obsolescence);
• anticiper les “enablers” qui vont permettre de répondre aux enjeux métier en amont des projets;
• valider les initiatives stratégiques, détecter les conflits et vérifier la faisabilité;
• coordonner les changements (roadmap, vitesse, capacité de transformation de l'entreprise, de son SI et de son organisation).

Conclusion

Nous avons vu dans cet article comment traduire les visions métier et tech en stratégie de transformation du SI.
Il faut commencer par maîtriser son patrimoine applicatif pour avoir une vision rationnelle du SI et donc une baseline solide pour les études et travaux à mener.
La transformation nécessite aussi un cadre directeur pour avoir la direction globale et savoir comment faire, ce cadre va évoluer de manière continue pour donner une vision macro du découpage cible du SI et de sa trajectoire de transformation grâce à des cartographies ciblées et valorisées, ainsi que des principes et modèles à la disposition des équipes.
Le pilotage de la transformation passe par une gestion des enablers technologiques et des assets communs sous forme de “portefeuille produits” et par une capacité d’Architecture d’Entreprise, nous reviendrons prochainement plus en détail sur cette capacité à développer dans un prochain article.

Références :

1. Adrien Saunier, Duck Conf 2024 : Automatisation dans la cartographie d’un SI en mouvement avec Backstage (REX Decathlon)
2. Publication Tech trends 2025 - OCTO Pulse
3. Cycle de vie technologique dans l’outil LeanIX : Technology Lifecycle Management: Key Stages & Challenges|