Le risque d’une démarche d’architecture d’entreprise est de produire beaucoup de documentation sans améliorer les décisions. Pour éviter cela, chaque livrable doit jouer un rôle dans une chaîne de justification : pourquoi transformer, quelles capacités construire, quelles informations maîtriser, quelles applications mobiliser et quelle fondation technique retenir ?
1. Commencer par adapter TOGAF au problème
Le cas MediSupply ne cherche pas à appliquer mécaniquement l’intégralité de TOGAF. Il concentre l’exercice sur les phases A à D, simplifie la documentation pour un contexte académique, priorise les processus critiques et produit progressivement les livrables. Il combine TOGAF avec BPMN, UML, une utilisation conceptuelle d’ArchiMate et des principes issus d’ITIL, COBIT et DAMA-DMBOK.
Le premier enseignement pratique est donc le tailoring : la méthode doit servir le contexte, et non l’inverse.
2. Phase A : rendre la transformation intelligible
La vision d’architecture doit fournir une compréhension commune aux décideurs métier et aux équipes techniques. Dans l’étude, le diagramme conceptuel identifie les acteurs, les principaux blocs fonctionnels et les grands flux d’information afin de rendre visible l’intention de transformation.
À ce stade, la question essentielle est : pourquoi transformer ? La réponse doit expliciter objectifs, périmètre, parties prenantes et résultats recherchés avant d’entrer dans la solution.
3. Phase B : traduire les objectifs en capacités et processus
L’architecture métier décrit comment l’organisation doit fonctionner. Dans le cas étudié, l’analyse part notamment des commandes, stocks, logistique, traçabilité et reporting. La cible cherche à harmoniser les processus, réduire les ressaisies, fiabiliser les référentiels et clarifier les responsabilités.
Une architecture métier utile ne décrit donc pas seulement un organigramme : elle établit les capacités que l’organisation doit posséder pour atteindre ses objectifs.
4. Phase C : déterminer les données et applications nécessaires
Le cas distingue architecture des données et architecture applicative. La première porte sur les référentiels, identifiants, gouvernance, qualité, traçabilité et fiabilité des flux. La seconde organise les services applicatifs, l’intégration et le reporting.
La cible ne préconise pas le remplacement immédiat de toutes les applications : elle combine modernisation, encapsulation, création de nouveaux services et décommissionnement contrôlé.
5. Phase D : construire la fondation technique sans perdre le fil métier
La fondation technologique proposée dans MediSupply comprend notamment intégration par API et événements, services modulaires, sécurité centralisée, haute disponibilité, observabilité, DevSecOps, sauvegarde et reprise. Mais l’étude précise que le choix exact des technologies doit encore être évalué selon les coûts, compétences, contraintes réglementaires, compatibilité et hébergement.
Autrement dit, la Phase D ne doit pas transformer l’architecture en catalogue de produits. Elle traduit des exigences en capacités techniques.
6. Utiliser les matrices pour prouver la cohérence
Une des dimensions les plus opérationnelles du cas est l’utilisation de matrices de traçabilité :
La matrice Objectifs/Capacités relie par exemple réduction des délais, exactitude des stocks, traçabilité, reporting ou satisfaction client aux capacités correspondantes. Une autre matrice relie les capacités aux applications, puis les applications aux technologies. Enfin, les exigences sont associées aux composants d’architecture qui doivent y répondre.
Ces matrices constituent un antidote aux décisions technologiques isolées : elles obligent à expliciter la raison d’être d’un composant.
7. Transformer les écarts en actions
Le passage de la baseline à la cible doit être traduit en écarts observables. Le cas associe ainsi certains écarts techniques à des actions : interfaces batch vers API et événements, infrastructure insuffisamment documentée vers inventaire et standardisation, authentification distribuée vers gestion centralisée des identités, journalisation fragmentée vers logs centralisés.
Le même principe s’applique aux domaines métier, données et applications. L’écart n’est utile que s’il devient une décision ou une action de transformation.
8. Faire de l’architecture un mécanisme de gouvernance
L’étude prévoit une revue de conformité pour chaque projet ou lot de transformation. Elle interroge successivement l’alignement stratégique, le processus métier, la source de référence des données, la réutilisation applicative, la standardisation des interfaces, la sécurité, la conformité technologique, la résilience, l’exploitation et le plan de migration.
Cette approche transforme l’architecture en discipline de décision continue : un projet n’est pas seulement évalué sur sa livraison, mais aussi sur sa cohérence avec la trajectoire d’ensemble.
9. Checklist pratique en dix questions
- Pourquoi transformons-nous ?
- Quels objectifs métier doivent être atteints ?
- Quelles capacités faut-il créer ou renforcer ?
- Quels processus doivent être harmonisés ou repensés ?
- Quelles données de référence doivent être maîtrisées ?
- Quelles applications supportent réellement ces capacités ?
- Quelles technologies sont nécessaires, et pourquoi ?
- Quels écarts séparent la baseline de la cible ?
- Quels paliers de transformation permettent de réduire le risque ?
- Comment contrôler la conformité des projets à l’architecture ?
Conclusion
TOGAF apporte le plus de valeur lorsqu’il permet de maintenir une continuité de raisonnement entre la stratégie et la technologie. Les diagrammes, catalogues et matrices ne sont alors pas une finalité documentaire : ils constituent des instruments de traçabilité et de décision.
La question centrale devient moins « quelle architecture voulons-nous dessiner ? » que « pouvons-nous expliquer, pour chaque choix, quel objectif, quelle capacité ou quelle exigence il sert ? ». C’est à cette condition que l’architecture d’entreprise devient une véritable discipline de transformation.
Fondements de l’analyse
MediSupply — application académique de TOGAF ADM
Ce tutoriel synthétise la logique méthodologique du cas d’étude : adaptation de TOGAF, phases A à D, matrices de traçabilité, analyses d’écarts et revue de conformité. Les éléments proposés dans le cas ne sont pas présentés comme des déploiements réels.