Architecture Applicative - Mise en contexte

Luc Bories

août 5, 2025 - 8 minutes de lecture - 1701 mots

Êtes-vous concerné par l’Architecture Applicative?

Si vous êtes développeur vous aimeriez comprendre comment les éléments applicatifs interagissent entre eux; comment doit fonctionner un traitement applicatif particulier, avec quels résultats attendus; de quelle manière un utilisateur doit utiliser un écran de saisie ou de consultation.

Si vous êtes spécialiste infrastructure, vous avez besoin de connaître la nature et la volumétrie des données stockées et échangées; la fréquence et la charge requise par chaque traitement applicatif; l’agencement des différentes solutions applicatives entre elles au sein du système d’information (SI).

Si vous êtes spécialiste en sécurité, vous souhaitez connaître où se trouvent les données sensibles, par qui sont-elles consultées et modifiées; quelles sont les interactions avec le monde extérieur.

Si vous êtes décideur ou architecte ou gestionnaire/chargé de projet, vous voulez avoir une vue d’ensemble du fonctionnement du SI.

Mais voilà, parfois la notion d’architecture n’est pas mise en œuvre et les éléments de documentation pour décrire l’existant et la cible n’existent pas. Certains documents décrivent parfois une partie précise du SI orientée pour les besoins d’un certain groupe de lecteurs.

Pourtant la solution existe, elle consiste à suivre les grands principes de l’Architecture IT en décrivant l’Architecture Applicative de tout ou partie du système d’information.

Vue d’ensemble de l’Architecture IT

Pour bien comprendre ce qu’est l’Architecture Applicative, il faut commencer par les différentes manières de représenter l’Architecture IT.

Il faut bien comprendre que selon la portée de l’architecture, la taille et l’organisation du SI, ainsi que la culture et les méthodes de l’entreprise, le découpage de même que les noms des étapes peuvent varier.

Tout part d’un besoin au sein d’un processus métier.

L’objectif est alors de représenter les fonctions et utilisateurs impliqués au travers de cas d’usages, c’est l’Architecture Métier ou Architecture d’Affaires.

Si les changements concernent l’organisation des applications (blocs fonctionnels, flux intra et inter-applicatifs, interface utilisateur), on parle alors de l’Architecture Applicative.

Pour documenter le détail des besoins, les fonctions impactées sont spécifiées: on parle d’Architecture Fonctionnelle.

Tout ce qui a trait aux données utilisées (nomenclature, normes, méthodes, outils) est documenté dans l’Architecture de Données.

Enfin, la conception des modifications à apporter aux composants logiciels en utilisant des modèles logiques (module, composant, classes) est nommée l’Architecture Applicative Logique ou Architecture Logicielle.

Et pour finir, l’implémentation avec les technologies sélectionnées (SGBD, serveurs, middleware…) va se faire en utilisant l’Architecture Technique.

Définition de l’Architecture Applicative

Comme nous l’avons vu précédemment, l’Architecture Applicative n’est pas une notion figée et invariable appliquée uniformément par tous.

Non, il s’agit de principes directeurs appliqués au sein d’une méthode ou d’un cadre d’architecture (architecture framework) souvent défini dans l’Architecture d’Entreprise.

Les grandes idées de l’Architecture Applicative sont de décrire à haut niveau une hiérarchie d’applications, de blocs ou composants, de fonctionnalités, d’entités. Chaque élément peut interagir avec d’autres au sein ou en dehors de son contenant.

Il faut bien voir que le principe d’Architecture Applicative peut s’appliquer à des cas de figure très variés. C’est pourquoi le principe est souple et que plusieurs cadres existent.

En effet, les projets suivants ont tous besoin d’une Architecture Applicative, pourtant ils sont très différents les uns des autres:

mise en oeuvre d’un progiciel sur site sur étagère, à configurer
mise en oeuvre d’un progiciel sur site associé à du développement sur mesure
mise en oeuvre d’une solution SaaS à intégrer aux autres briques applicatives
sous-traitance d’un processus applicatif complet à un prestataire
développement d’une application sur grand système (mainframe)
développement d’une application web 3-tiers
développement d’une application à base de micro-services
développement d’une application orientée service
développement d’une application répartie basée sur des événements d’affaires circulant sur un bus applicatif
développement d’une application entièrement dans le Cloud en connectant des services en ligne
développement d’une application pour mobile
développement d’une application pour ordinateur personnel
développement d’une application pour objet connecté
développement d’une application pour machine industrielle
développement d’une application pour calculateur scientifique

Les déclinaisons de l’Architecture Applicative

L’Architecture Applicative peut aussi regrouper un ensemble de sous-domaines architecturaux qui peuvent parfois éclipser le nom même d’Architecture Applicative:

Architecture Logicielle
Architecture d’Intégration
Architecture de Données
Architecture Fonctionnelle L’Architecture Logicielle va plus être orientée développement et cela se retrouve par les termes utilisés. On va ici parler de composants, de modules, de librairies, de framework, de modèle de données, d’expérience utilisateur, de l’interface utilisateur, de langages…

L’Architecture d’Intégration est en charge de décrire comment les applications vont s’intégrer les unes avec les autres:

la nature, la description et le format des données échangées
la nature et le format des flux de communication synchrones et asynchrones
la description des éléments propre à l’intégration L’Architecture de Données veille à conserver une cohérence et une traçabilité des données du SI. Elle décrit les modèles logiques de données, les modèles de description de données et les modèles physiques de données. Elle participe aussi en établissant des règles sur le choix des outils de stockage et d’échange de données, les bonnes pratiques, l’anonymisation et l’optimisation du traitement des données.

L’Architecture Fonctionnelle est souvent la partie la plus mise en œuvre car elle décrit les besoins métier ou d’affaires en spécifications fonctionnelles utilisables par les concepteurs ou développeurs.

De manière générale, l’Architecture Applicative apporte les éléments suivants:

une vue globale des éléments applicatifs
une description précise du comportement attendu de chaque élément
une description des interactions possibles entre les éléments
une description des données utilisées et échangées par les éléments
une feuille de route des grandes étapes de mise en oeuvre
un guide de description et d’implémentation
des modèles réutilisables de solutions (voir Architecture de Solution/LIEN)

Les facettes de l’Architecture Applicative

Une application peut s’opérer de manière plus ou moins visible vis à vis des utilisateurs internes ou clients. Le frontend au contact des utilisateurs, le backend dans les coulisses La partie en visibilité des utilisateurs (internes ou clients) se nomme le frontend. Un des aspects essentiels à surveiller est ici l’expérience utilisateur, c’est à dire le ressenti à l’usage.

Même si de nos jours, il est essentiellement question d’application web ou mobile, il ne faut pas oublier tout le pan des applications des postes de travail et l’existant grand système.

Ainsi, la description du frontend comprend l’interface utilisateur, les interactions entre les éléments de l’interface et l’utilisation des services applicatifs du backend.

La partie en arrière-plan qui va traiter les données en exécutant des traitements sans interactions avec les utilisateurs principaux s’appelle le backend. Ici, la sécurité, la résilience, la performance, la scalabilité (faculté de monter facilement en charge) sont les maîtres-mots.

La documentation du backend concerne donc principalement les schémas de données, les échanges de données, l’intégration entre applications, les traitements batchs et les services applicatifs.

Les méthodes de l’Architecture Applicative

Comme nous l’avons vu, l’Architecture Applicative regroupe une grande variété de contextes et cas d’utilisation totalement différents.

Cela concerne des applications nouvelles, web ou mobile, aussi bien que applications existant depuis plusieurs décennies, époque où l’internet le PC n’existaient pas.

Ensuite, selon la culture et l’activité des entreprises, les besoins en termes de sécurité, d’agilité, de conformité… sont très différents.

Entre une institution financière internationale et une startup dans les jeux gratuits sur mobile, les différences de besoins d’Architecture Applicative sont énormes.

Et même au sein d’une Architecture d’Entreprise, la nature d’une application particulière peut amener à utiliser une méthode différente.

En termes de méthodes, plusieurs grands courants architecturaux sont disponibles depuis longtemps tels que:

l’approche Donnes/Traitements (framework Zachman, Merise), démarche top-down en séquence, lourde et verbeuse
l’approche Composant plus adaptée aux systèmes distribués et orientés objets (framework Zachman), méthode assez rigide et manquant parfois de pragmatisme
l’approche orienté service (SOA) met en oeuvre des services permettant d’avoir un faible couplage avec l’extérieur de l’application
l’approche des processus métier est basée sur une méthodologie de modélisation et un formalisme de description (UML). UML s’est en effet imposé en tant que standard de formalisation de la modélisation. Toutefois il n’y a pas de norme unique pour la modélisation. Chaque fournisseur peut avoir sa propre méthode utilisant UML. Les outils utilisés sont le BPM (Business Process Modeling) ou le BPR (Business Process Re-engineering) tels que Mega, Erwin/Casewise.

Les livrables de l’Architecture Applicative

La liste des livrables fournis par l’Architecture Applicative varie en fonction de l’organisation, des normes et méthodes de l’architecture dans son ensemble.

Toutefois, voici les principaux livrables possibles:

environnement de conception et développement
la liste des briques techniques requises pour la conception et l’implémentation tels que les librairies, progiciels, solutions SaaS, design patterns (motifs de conception) à utiliser…
les outils de modélisation et de conception
les outils de développement (IDE)
les standards et méthodes de développement à utiliser
la description fonctionnelle
les diagrammes des structures de données, des traitements, des enchaînements, des interfaces
les maquettes de l’interface utilisateur
les spécifications fonctionnelles (requis, attendus, contraintes)
les spécifications de l’intégration
les spécifications de conception logicielle

Le rôle de l’Architecte Applicatif

L’Architecte Applicatif a souvent un rôle central car il est un des seuls à avoir une vision globale du fonctionnement applicatif avec les aspects fonctionnels, techniques et architecturaux.

En outre, il procède par étapes en élaborant d’abord une ébauche de la vue d’ensemble puis en affinant successivement les composants à implémenter. L’Architecte Applicatif a alors pour principaux rôles:

de recenser les besoins fonctionnels, les contraintes et règles métier ou d’affaires
d’élaborer et communiquer les principes directeurs de l’architecture applicative
de définir les besoins techniques
de participer aux choix technologiques
de créer l’Architecture Applicative
de participer ou de créer la conception logicielle
de supporter les concepteurs et développeurs
de participer aux phases de tests, d’intégration, d’acceptation et de performance L’Architecture Applicative au service de l’urbanisation du SI

L’urbanisation du système d’information (SI) décrit les constituants du SI et les interactions entre ces éléments, sans entrer dans le détail de la conception et de l’implémentation.

Son but est de s’assurer d’une cohérence globale au niveau du SI.

Ainsi, l’Architecture Applicative participe à maintenir l’évolutivité et l’uniformité du SI en respectant les règles et contraintes édictées et en veillant à décliner ces pratiques dans toute la granularité qu’elle va définir.

L’objectif de l’Architecture Applicative est donc de servir à la fois les concepteurs et développeurs. Ceci afin d’implémenter la solution mais aussi afin de veiller à la cohérence globale, à la sécurité, à la résilience et à l’évolutivité du système d’information.