Les cadres d’architecture d’entreprise comme TOGAF (The Open Group Architecture Framework) ont traditionnellement été associés à une planification détaillée, à une documentation étendue et à une vision à long terme. Les méthodologies agiles, en revanche, privilégient la livraison itérative, l’adaptabilité et les retours des clients. Pour de nombreuses organisations, l’intégration de ces deux approches distinctes crée des frictions. Le conflit perçu réside dans la tension entre le besoin de gouvernance architecturale et le désir d’itérations rapides.
Ce guide explore comment les organisations peuvent appliquer avec succès les principes de TOGAF dans des environnements agiles. Nous examinerons des stratégies concrètes pour aligner la Méthode de développement d’architecture (ADM) sur des cycles de développement itératifs, en veillant à ce que la structure soutienne la flexibilité plutôt que de la freiner. En comprenant les subtilités de ces deux cadres, les dirigeants peuvent construire des systèmes robustes tout en restant réactifs aux changements.
🧩 Comprendre les cadres fondamentaux
Pour intégrer efficacement, nous devons d’abord comprendre la nature fondamentale de chaque approche, sans nous appuyer sur des termes à la mode.
🏛️ La Méthode de développement d’architecture TOGAF
TOGAF propose une approche structurée pour concevoir, planifier, mettre en œuvre et gouverner une architecture d’information d’entreprise. Le cœur de ce cadre est le cycle ADM, qui se compose de plusieurs phases :
- Phase A : Vision architecturale – Définir le périmètre et les exigences des parties prenantes.
- Phase B : Architecture métier – Définir la stratégie et les processus métiers.
- Phase C : Architectures des systèmes d’information – Couvrant les architectures données et applications.
- Phase D : Architecture technologique – Définir l’infrastructure et les normes techniques.
- Phase E : Opportunités et solutions – Planifier la feuille de route de mise en œuvre.
- Phase F : Planification de migration – Séquencer les étapes de transition.
- Phase G : Gouvernance de la mise en œuvre – S’assurer que la solution correspond au design.
- Phase H : Gestion des changements architecturaux – Gérer les changements apportés à l’architecture.
Traditionnellement, ce cycle est perçu comme linéaire ou semi-linéaire, nécessitant souvent une définition complète avant le début de la mise en œuvre. C’est là que surgit la friction avec l’agilité.
⚡ L’état d’esprit agile
L’agilité n’est pas seulement un ensemble de pratiques ; c’est un état d’esprit centré sur le Manifeste Agile. Les principes clés incluent :
- Les individus et les interactions plutôt que les processus et les outils.
- Le logiciel fonctionnel plutôt que la documentation exhaustive.
- La collaboration avec le client plutôt que la négociation de contrats.
- Répondre aux changements plutôt que suivre un plan.
Les équipes agiles travaillent généralement en itérations courtes (sprints) pour livrer des incréments fonctionnels. Elles s’appuient sur des retours continus pour ajuster la direction du produit. Dans ce contexte, un plan d’architecture rigide peut ralentir la livraison de valeur.
🤝 Le défi d’intégration
Le défi principal de la combinaison de TOGAF et d’Agile réside dans la différence d’horizon temporel et de granularité de planification. TOGAF considère souvent le niveau entreprise sur plusieurs années, tandis qu’Agile opère sur des semaines ou des mois. Si l’architecture est trop rigide, elle étouffe la capacité de l’équipe à pivoter. Si elle est trop souple, l’organisation court le risque de dette technique et de fragmentation.
Voici une analyse des points où les tensions se produisent généralement :
| Aspect | Orientation TOGAF | Orientation Agile | Conflit potentiel |
|---|---|---|---|
| Planification | Feuille de route à long terme | Backlog de sprint à court terme | Quel degré de détail futur est nécessaire ? |
| Documentation | Modèles complets | Logiciel fonctionnel | Le surcroît de documentation est-il justifié ? |
| Pr prises de décision | Gouvernance centralisée | Propriété décentralisée | Qui approuve le changement ? |
| Changement | Évolution contrôlée | Adaptation encouragée | Comment gérer l’écart ? |
Reconnaître ces différences permet aux architectes de concevoir un modèle hybride qui respecte les forces des deux approches.
🔄 Adapter la Méthode de Développement d’Architecture aux cycles Agile
La Méthode de Développement d’Architecture n’a pas besoin d’être abandonnée. Elle peut au contraire être rendue itérative. Le concept de « ADM itérative » permet que le travail d’architecture s’effectue en parallèle du travail de développement, plutôt que de le précéder entièrement.
🌱 Vision architecturale itérative
La phase A (Vision) ne doit pas être un événement ponctuel. Dans un environnement Agile, la vision est considérée comme un document vivant. Elle fournit une boussole mais permet des ajustements en fonction des retours du marché. Les architectes collaborent avec les Product Owners pour s’assurer que la vision s’aligne sur la feuille de route du produit.
Les actions clés incluent :
- Définir des principes de haut niveau qui restent constants.
- Identifier les contraintes non négociables (sécurité, conformité).
- Diviser la vision en épicées architecturales actionnables.
🏗️ Définition de l’architecture juste à temps
Dans les modèles traditionnels, les quatre domaines (Affaires, Données, Application, Technologie) sont entièrement définis avant le début du développement. L’Agile suggère de définir uniquement ce qui est nécessaire pour avancer. Cela est souvent appelé « architecture juste à temps ».
Par exemple :
- Sprint 1-3 : Se concentrer sur l’architecture des affaires et la logique d’application de haut niveau.
- Sprint 4-6 : Affiner l’architecture des données au fur et à mesure que des entités de données spécifiques sont requises.
- Sprint 7+ : Détailler l’architecture technologique pour les environnements de déploiement.
Cette approche réduit les pertes. Les architectes n’ont pas à perdre de temps à modéliser des composants qui pourraient être abandonnés au cours d’une itération.
🏗️ La piste d’architecture
Un concept crucial pour cette intégration est la « piste d’architecture ». Ce terme fait référence à l’infrastructure technique et aux principes architecturaux qui doivent être en place pour soutenir le développement futur de fonctionnalités. Sans piste, les développeurs pourraient devoir s’arrêter et construire des composants fondamentaux au milieu d’un sprint de fonctionnalité, ce qui entraîne des retards.
Pour maintenir une piste saine :
- Identifier les facilitateurs : Déterminer quel travail technique est nécessaire pour permettre la valeur future des affaires.
- Allouer une capacité : Réserver une partie de la capacité du sprint (par exemple, 20 %) aux facilitateurs architecturaux.
- Automatiser les normes : Utiliser l’infrastructure comme code pour imposer les normes techniques sans goulets d’étranglement de revue manuelle.
Cela garantit que l’équipe Agile dispose des outils et des cadres dont elle a besoin sans attendre la fin d’un projet d’architecture massif.
🛡️ Gouvernance légère
La gouvernance dans un environnement Agile doit être légère. Les processus d’approbation rigides tuent l’élan. L’objectif est de garantir la conformité et la qualité sans créer de goulets d’étranglement.
📝 Registres des décisions architecturales (ADRs)
Au lieu de documents d’architecture volumineux, les organisations peuvent utiliser des Registres des décisions architecturales. Un ADR capture une décision architecturale importante ainsi que son contexte et ses conséquences. C’est un document léger qui réside dans le dépôt de code.
Les avantages des ADR incluent :
- Traçabilité : Savoir pourquoi une décision a été prise des mois ou des années plus tard.
- Collaboration : Les membres de l’équipe peuvent examiner et commenter les décisions facilement.
- Transparence : L’historique des décisions est accessible à tous.
🔍 Le comité de revue de l’architecture
Le comité de revue de l’architecture (ARB) traditionnel peut devenir un goulot d’étranglement. En mode Agile, l’ARB doit fonctionner comme un organe consultatif plutôt que comme un gardien des accès. Les revues doivent avoir lieu aux jalons clés plutôt qu’à chaque sprint.
Pensez à ces ajustements :
- Concentrez-vous sur les risques : Revoyez uniquement les décisions à haut risque pouvant impacter l’entreprise.
- Revue asynchrone : Permettez aux architectes de fournir leurs retours de manière asynchrone afin d’éviter les conflits de planning.
- Revue par les pairs : Encouragez les développeurs à revue mutuellement la conformité architecturale avant la revue formelle par l’ARB.
👥 Rôles et responsabilités
Une intégration réussie nécessite des définitions de rôles claires. Le rôle traditionnel de « chef architecte » doit souvent évoluer vers un modèle plus distribué.
🧑💼 L’architecte d’entreprise
L’architecte d’entreprise se concentre sur la vision à long terme. Il définit les normes, principes et modèles qui guident l’organisation. Il s’assure que les différentes équipes ne construisent pas des silos incompatibles.
🧑💻 L’architecte système
L’architecte système travaille plus près des équipes de développement. Il traduit les principes d’entreprise en conceptions techniques spécifiques pour une solution particulière. Il agit comme un pont entre la stratégie de haut niveau et le code.
🏃♂️ L’architecte Agile
Certaines organisations intègrent directement des architectes dans les équipes Agile. Ces personnes aident l’équipe à prendre des décisions alignées sur la stratégie globale tout en maintenant la vitesse de développement. Elles participent à la planification des sprints et à l’ajustement du backlog.
🧭 Le Product Owner
Le Product Owner représente la valeur métier. Il collabore avec les architectes pour s’assurer que les contraintes techniques sont comprises dans le contexte des objectifs métiers. Il priorise les éléments facilitant l’architecture aux côtés des user stories.
🚧 Les pièges courants à éviter
Même avec un plan solide, l’intégration peut échouer si des pièges spécifiques sont ignorés. Être conscient de ces erreurs courantes peut faire économiser un temps et des ressources considérables.
- Surconception : Essayer de concevoir pour chaque scénario futur possible conduit à des systèmes surdimensionnés. Concevez en fonction des besoins actuels, en gardant à l’esprit l’extensibilité.
- Sous-conception : Ignorer les contraintes architecturales entraîne une dette technique devenue ingérable. Assurez-vous que les exigences non fonctionnelles (performance, sécurité) sont prises en compte.
- Fentes de communication : Les architectes et les développeurs parlent souvent des langues différentes. Utilisez des diagrammes et des modèles accessibles à toute l’équipe.
- Ignorer la dette technique : Les équipes Agile privilégient souvent les fonctionnalités au détriment du restructurage. Établissez une règle selon laquelle un pourcentage de chaque sprint doit être consacré à la dette technique.
- Surcharge d’outils : N’optez pas pour des outils de modélisation complexes nécessitant une formation. Gardez la documentation simple et intégrée au flux de développement.
📊 Mesurer le succès
Comment savez-vous si l’intégration fonctionne ? Vous avez besoin de métriques qui reflètent à la fois l’état architectural et la vitesse de livraison.
📈 Métriques de santé architecturale
- Taux de conformité : Pourcentage des solutions conformes aux normes définies.
- Ratio de la dette technique : Ratio du travail de restructurage par rapport au travail sur de nouvelles fonctionnalités.
- Réutilisabilité : Nombre de composants partagés utilisés dans différents projets.
🚀 Métriques de livraison
- Délai de livraison : Temps écoulé entre l’idée et le déploiement.
- Fréquence de déploiement : Fréquence à laquelle le code est publié.
- Taux d’échec des modifications : Pourcentage des déploiements entraînant une panne.
En suivant ces métriques, la direction peut prendre des décisions fondées sur les données quant à l’endroit où investir dans l’architecture ou où assouplir les contraintes.
🤔 Questions fréquemment posées
❓ TOGAF peut-il fonctionner avec Scrum ?
Oui. Les phases du ADM peuvent être mappées sur les cycles de sprint. Par exemple, les phases B et C peuvent être explorées sur plusieurs sprints. L’essentiel est de considérer le ADM comme un cycle d’exploration plutôt qu’une méthode en cascade linéaire.
❓ Quelle quantité de documentation est nécessaire ?
La documentation doit être suffisante pour maintenir le système, mais pas excessive. Un diagramme qui tient sur une seule page est souvent préférable à un document de 50 pages. Concentrez-vous sur la documentation qui ajoute de la valeur et facilite la maintenance.
❓ Et si les exigences métiers changent au milieu du sprint ?
C’est un principe fondamental de l’Agile. L’architecture doit être suffisamment souple pour s’adapter aux changements. Utilisez des couches d’abstraction et des interfaces pour déconnecter les composants, afin que les modifications dans une zone n’entraînent pas la panne de l’ensemble du système.
❓ Avons-nous besoin d’un cadre Agile distinct comme SAFe ?
Pas nécessairement. Bien que des cadres comme SAFe (Scaled Agile Framework) apportent une structure aux grandes organisations, TOGAF peut être adapté sans adopter un cadre à grande échelle. Le choix dépend de la taille et de la complexité de l’organisation.
❓ Comment gérons-nous les systèmes hérités ?
Les systèmes hérités nécessitent souvent une approche différente. Vous devrez peut-être créer un modèle « Figuier étrangleur » où de nouvelles fonctionnalités sont développées autour du système hérité, le remplaçant progressivement. TOGAF aide à cartographier la transition depuis l’état hérité jusqu’à l’état cible.
🔍 Points clés
Intégrer TOGAF à Agile ne consiste pas à choisir l’un plutôt que l’autre. Il s’agit de trouver un équilibre entre structure et agilité. En rendant la méthode de développement d’architecture itérative, en adoptant une gouvernance légère et en définissant clairement les rôles, les organisations peuvent atteindre à la fois stabilité et rapidité.
Le succès dépend de la communication, de la flexibilité et d’une compréhension partagée des objectifs. Lorsque les équipes d’architecture et de développement travaillent en partenariat, le résultat est une entreprise résiliente capable de s’adapter aux évolutions du marché sans compromettre la qualité ni la conformité.
Commencez petit. Testez l’approche au sein d’une équipe. Mesurez les résultats. Ajustez le processus. Répétez. Cette approche itérative de l’architecture elle-même reflète la philosophie Agile qu’elle cherche à soutenir.
