Du AS-IS au TO-BE : pourquoi toute transformation doit commencer par l’architecture

1. Un cas d’étude pour raisonner sur la transformation

L’étude MediSupply adapte TOGAF à un contexte académique : concentration sur les phases A à D de l’ADM, documentation simplifiée, priorité aux processus critiques et production progressive des livrables. Elle mobilise également BPMN, UML, ArchiMate de manière conceptuelle, ainsi que des principes issus d’ITIL, COBIT et DAMA-DMBOK.

L’intérêt n’est donc pas de défendre une architecture technologique particulière, mais d’observer la discipline de raisonnement qui conduit de la stratégie vers une cible cohérente.

2. Comprendre le AS-IS avant de dessiner la cible

Dans TOGAF, l’analyse des écarts distingue la Baseline Architecture, c’est-à-dire l’organisation actuelle, de la Target Architecture, correspondant au fonctionnement cible, puis identifie les transformations nécessaires pour passer de l’une à l’autre.

Dans le cas étudié, la baseline faisait apparaître des canaux multiples, des ressaisies manuelles, des pratiques logistiques différentes, une visibilité insuffisamment immédiate des stocks, des données dupliquées et un reporting reposant sur des retraitements manuels.

3. Le TO-BE décrit d’abord une capacité organisationnelle

La cible métier proposée ne commence pas par des serveurs ou des API. Elle vise un processus unifié de gestion des commandes, des règles communes, une meilleure visibilité des stocks, une traçabilité intégrée, des référentiels uniques, une automatisation progressive, un reporting consolidé et des responsabilités clairement définies.

C’est seulement ensuite que les applications, les données et les technologies sont positionnées pour supporter ce fonctionnement.

4. La traçabilité architecturale évite les technologies sans justification

La synthèse des phases A à D formalise une chaîne particulièrement utile :

Cette chaîne matérialise une exigence simple : chaque choix technique doit pouvoir être relié à une capacité ou à une exigence située en amont. L’étude utilise ainsi des matrices Objectifs/Capacités, Capacités/Applications, Applications/Technologies et Exigences/Composants pour vérifier la cohérence.

5. Métier, données, applications et technologies forment un système

La synthèse du cas formule les questions successives des phases TOGAF : pourquoi transformer ? comment l’entreprise doit-elle fonctionner ? quelles données et applications sont nécessaires ? sur quelle fondation technologique ?

Cette progression empêche de traiter indépendamment le métier, les données, les applications et l’infrastructure. Une exigence de traçabilité, par exemple, peut avoir des conséquences simultanées sur les processus, les référentiels, les applications, les habilitations, les journaux et les mécanismes de sécurité.

6. L’analyse des écarts transforme une vision en programme de changement

Comparer AS-IS et TO-BE ne consiste pas seulement à dresser deux schémas. Il faut identifier ce qui doit être conservé, créé, modifié ou retiré. Les écarts deviennent alors des besoins de transformation.

C’est à ce moment que l’architecture commence à préparer la feuille de route : les transformations peuvent être regroupées, dépendances identifiées et architectures de transition envisagées.

7. Une bonne cible n’impose pas nécessairement une rupture brutale

Dans la Phase D du cas MediSupply, l’architecture technique proposée est hybride, modulaire et sécurisée, tout en prévoyant le maintien temporaire de certains systèmes historiques. La conclusion insiste sur une transformation progressive de l’existant.

Elle précise également que le choix exact des technologies n’est pas arrêté et qu’il doit être évalué selon les coûts, les compétences disponibles, les exigences réglementaires, la compatibilité avec l’existant et les contraintes d’hébergement.

Cette réserve est essentielle : l’architecture définit des principes et des capacités avant de figer les produits.

8. L’architecture doit être gouvernée

Le cas prévoit un comité de pilotage pour les orientations et investissements, un comité d’architecture chargé de valider les architectures et gérer les écarts, ainsi qu’une équipe projet responsable de la modélisation et des livrables.

Le processus proposé va de l’identification d’un besoin à l’analyse métier, l’étude d’architecture, les validations, la mise en œuvre, le contrôle de conformité et le retour d’expérience. L’architecture devient ainsi un mécanisme continu de décision plutôt qu’un dessin produit une seule fois.

9. Neuf principes transférables

1. Commencer par les motivations, pas par les technologies.
2. Documenter le AS-IS avec suffisamment de précision pour comprendre les problèmes.
3. Décrire le TO-BE en capacités métier avant de choisir les solutions.
4. Relier objectifs, processus, données, applications et technologies par une chaîne de traçabilité.
5. Analyser explicitement les écarts entre baseline et cible.
6. Conserver ce qui reste utile au lieu de remplacer systématiquement l’existant.
7. Construire des architectures de transition lorsque la cible ne peut être atteinte en une étape.
8. Évaluer les technologies selon coûts, compétences, réglementation et contraintes réelles.
9. Gouverner l’architecture dans le temps et capitaliser les retours d’expérience.

Conclusion

L’architecture d’entreprise n’est pas une couche supplémentaire de documentation placée au-dessus des projets. Elle constitue un mécanisme de cohérence entre stratégie, organisation, information et technologie.

Passer du AS-IS au TO-BE signifie comprendre où l’organisation se trouve, définir ce qu’elle veut être capable de faire, identifier les écarts puis organiser une trajectoire réaliste. Dans cette logique, la technologie n’est plus le point de départ de la transformation : elle devient l’une des réponses à des exigences préalablement comprises et structurées.