Quelle Architecture Applicative en 2021

Le choix d’une Architecture Applicative est une décision déterminante en ce qui concerne l’organisation des équipes, les méthodes de travail, les technologies à utiliser, les compétences à acquérir, les interactions avec les utilisateurs internes, les clients et les partenaires… Alors quelle architecture applicative en 2021?

Préambule

Cet article n’est pas orienté sur des choix technologiques ou des fournisseurs mais plus sur des choix architecturaux. En effet, il existe tellement de solutions techniques existantes dans tellement de cas de figure différents que nous ne pourrons pas en faire le tour avec un seul écrit. De futurs articles traiteront donc des sujets technologiques qui sont tout aussi importants.

A noter que nous parlerons d’entreprise pour alléger le texte mais cela concerne tout aussi bien les organisations gouvernementales, les associations, les établissements d’enseignement ou tout autre forme juridique permettant d’exercer une activité.

Avant de trouver l’Architecture Applicative qui convient le mieux à votre projet, à votre organisation, il convient de bien définir les hypothèses de départ: c’est l’objet de cet article. Parcourons ensemble les points essentiels pour définir votre Architecture Applicative.

Le contour d’une application

Le premier aspect à avoir en tête est la nature même d’une application: ne pas la résumer à du code. Pour bien définir une Architecture Applicative, il convient de noter qu’une application englobe les aspects besoins métiers, règles d’affaire, sécurité, réglementation, gestion des données, optimisation, résilience, intégration avec l’existant, interactions avec les utilisateurs, les clients ou partenaires, roadmap, respect des directives de l’Architecture d’Entreprise…

Commençons par se poser la question: qui utilise notre application?

Le périmètre de l’application

La première étape est de cerner le périmètre de l’application, en terme d’utilisateurs internes, de clients, de partenaires, de fournisseurs. Quel est l’objet de l’application? Servir une petite équipe en interne ou offrir un service à des millions d’utilisateurs en ligne.

En effet, les cas seront traités différemment selon la nature et la localisation des utilisateurs:

Une application purement interne pour une équipe, un service, un département, un site, un pays ou un ensemble de pays.
Une application à destination des partenaires, fournisseurs ou distributeurs.
Une application publique concernant un petit ou un très grand nombre d’utilisateurs au sein d’un ou plusieurs pays.

Le type d’utilisateur aura notamment un impact sur les aspects de sécurité, de confidentialité et des réglementations associées. La localisation des utilisateurs sera une informations importantes car elle permettra de mettre en oeuvre ou non des stratégies d’optimisation et de disponibilité adaptées.

En outre, la nature des interactions est déterminantes pour les choix:

interface web
client desktop
échanges de données (fichiers, services web, messages, API)
client mobile ou tablette
automate: guichets automatiques ou robots d’usine par exemple

Pour avoir une large base d’utilisateurs, une interface web ou mobile est plus adaptée et sans doute moins compliqué et couteux qu’une interface pour ordinateur personnel.

Les besoins métiers

Connaître les besoins d’affaire de manière exhaustive et précise n’est pas toujours simple. En effet, ce n’est pas un exercice toujours facile de lister l’ensemble des fonctionnalités dont nous allons avoir besoin. De même pour les règles d’affaire à appliquer. Et partir d’un existant pour une refont applicative n’est pas forcément plus aisé.

Il arrive parfois qu’une application soit présente depuis plusieurs dizaines d’années et que les fonctionnalités ne soient pas complètement ou pas du tout documentées. Il faut alors replonger dans le code et en extraire les règles métier à adapter pour la nouvelle application.

En outre, chaque entreprise a selon son domaine d’intervention à satisfaire des contraintes légales, contractuelles ou de confidentialité. En particulier, la nature des données à gérer va influer sur les règles à respecter et les moyens à utiliser. Et même le vocabulaire peut être propre à un secteur d’activité ou à une entreprise.

Parmi les livrables:

L’Architecture d’Entreprise donne les guides à suivre pour définir et implémenter l’Architecture Applicative.
La roadmap des applications apporte des éléments pour déterminer le choix de l’architecture applicative et le calendrier à respecter.
Les règles métier spécifient les comportements à respecter sur des actions ou des traitements.
Les règles de validation spécifient la manière de valider des données.
Les fonctionnalités spécifient les blocs fonctionnels attendus pour l’application.
Les processus d’affaire ou cas d’utilisation spécifient le comportement attendu de l’application lors de son utilisation.
La cartographie des composants permet de découper une application en composants qui porteront chacun un lot de fonctionnalités.

Mais comme dans toute activité d’une entreprise, l’argent a son importance. Voyons comment la définition des budgets peut influencer les choix de l’Architecture Applicative.

Le budget de l’architecture applicative

Dans un monde idéal, les besoins métiers sont étudiés dans leur globalité puis:

Une Architecture d’Entreprise ou au moins une Architecture Applicative est alors définie globalement.
De là, des choix sont faits pour chaque application ou chaque composante applicative.
Les budgets sont alors chiffrés.
Les projets sont lancés.

Mais la réalité est souvent différente, un besoin métier est unitairement mis en avant avec un budget. A partir de ces éléments, une Architecture Applicative est définie tenant compte des contraintes de l’existant et du budget. Il en ressort une architecture de compromis. La répétition de ce scénario peut conduire à un système d’information formé d’applications qui cohabitent, sans harmonie et avec de fort besoins d’intégration.

Un autre cas de figure est la migration d’une grosse application monolithique en un ensemble d’applications qui cohabitent et s’échangent des informations. Le découpage s’opère souvent au niveau des fonctionnalités, du budget mais aussi au niveau des ressources humaines. Et si il n’existe pas un cadre fort, commun et transverse à respecter, des divergences peuvent apparaître en termes de méthodes, de technologies, d’intégrations: cela a pour conséquence des coûts supplémentaires non prévus pour interfacer les différentes applications et composants.

Une fois les choix effectués, un fonctionnement établi, des méthodes mises en place, quels sont les impacts de l’Architecture Applicative sur la vie de l’entreprise.

Les impacts du choix de l’architecture applicative

Les choix architecturaux ont des impacts forts sur plusieurs domaines de l’entreprise, et pas seulement au niveau applicatif:

L’existant doit plus ou moins s’adapter. Une application n’est que rarement totalement autonome et isolée. En général, de nombreuses interactions entre les systèmes sont à prévoir.
Les compétences sont à développer ou à acquérir.
Les méthodes sont à communiquer et appliquer.
Les nouveaux fournisseurs sont à choisir, les contrats des fournisseurs existant sont à renégocier.
Les partenaires sont à informer, voir font partie du projet s’ils doivent s’adapter.
Les équipes internes, les utilisateurs et les personnels du SI, doivent changer leurs habitudes, voir se former.
L’intégration entre composants applicatifs ou entre applications ou avec des fournisseurs et partenaires est à construire ou adapter.
Les budgets, souvent annuels, sont à adapter pour tenir compte des changements technologiques ou organisationnels.
Les roadmaps sont à synchroniser: une refonte d’une application ne peut pas toujours se mener de front avec une adaptation à des changements importants d’une autre application.

Après avoir parlé de besoins, de budgets et d’impacts, parlons concrètement des éléments à prendre en compte pour nous aider à répondre à la question: quelle Architecture Applicative en 2021? Commençons par le type d’application,

Le choix du type d’application

Comment choisir le type d’application à mettre en œuvre: achat de progiciels sur site, utilisation de progiciels SaaS, développent sur site / Cloud / hybride…

Pour faire le choix du type d’application, il est nécessaire de prendre en compte et de pondérer les éléments suivants:

Les besoins métiers immédiats et à venir (fonctionnalités).
Les projections en terme de charge de traitement et de nombre d’utilisateurs.
La cible de l’Architecture d’Entreprise et les orientations qu’elle amène.
L’existant en terme de matériels, d’hébergement, de fournisseurs, de contrats, d’applications, de compétences, d’organisation, de calendrier commerciale.
Les ressources financières disponibles ainsi que les prévisionnels.
Le niveau de rentabilité attendu.
Les enjeux de l’environnement économique, sanitaire, politique et réglementaire.

Détaillons un peu les possibilités pour la partie interface, le front-end.

Le choix pour le Frontend

La partie visible de l’application est souvent la plus mise en avant par les utilisateurs ou clients même si le moteur caché de l’application est tout aussi important. L’entreprise doit balancer les coûts, la pérennité des technologies et fournisseurs, l’adaptation aux goûts du jour pour ne pas paraître en retard, la sécurité et la facilité d’intégration.

Les possibilités offertes pour le frontend sont variées:

web principalement HTML et Javascript (pages web)
web purement Javascript (application web)
web avec des pages HTML générées dynamiquement par le backend.
écran 3270 pour mainframe
desktop Java
desktop Native (C, C++, C#…)
desktop Web (Electron…)
mobile, tablette (iOS, Android)
automate grand public (guichet de banque ou de vente de titre de transport, de validation de billet d’avion…)
automate spécialisé (machine outil, robot industriel…)
aucun: communication par des échanges de données

Dans la plupart des cas, le choix sera vite fait car la nature même des besoins d’affaire va cerner une ou quelques possibilités.

Vous avez déterminé quel est le meilleur choix pour réaliser la partie visible de votre application, cherchons maintenant à trouver comment implémenter la mécanique invisible et tout aussi cruciale, le backend.

Le choix pour le Backend

Quelle forme l’application va-t-elle prendre dans les coulisses du système d’information? Sera-t-elle hébergée sur site, dans le Cloud ou un peu des deux (hybride)? Sera-t-elle développée en interne ou sera issue de la configuration d’un progiciel sur site ou d’un service en ligne?

L’application peut ainsi prendre plusieurs formes dont:

monolithique
3-tiers : frontend / backend / base de données
n-tiers: hautement distribuée
serverless: l’application ne gère plus de serveur, elle utilise des ressources en ligne et appel des API spécialisées pour exécuter des traitements.
microservices: ensemble de micro-applications centrées chacune sur un domaine fonctionnel, dont les évolutions sont indépendantes les unes des autres et qui dialoguent entre elles à l’aide contrats (message, API, WS).

Par ailleurs, chacune des briques peut être un progiciel, un développement interne, un mixte des deux.

En outre, les traitements et données sont hébergés soit dans un centre de données de l’entreprise, au sein d’une infrastructure dans les nuages (cloud), sont mixtes entre le datacenter et le cloud (hybride) ou font appel à des services en ligne (SaaS).

Un autre aspect important concerne la gestion des données: comment les organiser, les stocker, les sauvegarder, les archiver, les interroger, les agréger…

Là encore, les besoins métier vont influer sur le choix en particulier: le volume de transactions, la charge et la fréquence des traitements, le niveau de sécurité et de résilience, le choix du frontend ainsi que le nombre et la localisation des utilisateurs vont être déterminants. Ensuite, la culture de l’entreprise, le budget, les projections et l’expérience des personnels vont finir de sceller le choix.

Mais une application ne vit généralement pas de manière isolée en autonomie complète. Elle a besoin d’échanger des informations avec les autres systèmes de l’entreprise, les fournisseurs, les partenaires, les filiales, les sites, les applications financières et administratives… C’est pourquoi le choix de l’intégration est tout aussi important pour la réussite du projet.

Le choix pour l’intégration

Une application ne vit que très rarement isolée de manière autonome. Elle a de plus en plus souvent besoin d’échanger des données avec d’autres applications de nature différente, à l’intérieur ou à l’extérieur de l’entreprise. Là aussi le choix de l’architecture d’intégration sera déterminant sur les possibilités, les performances, la sécurité et la rapidité de déploiement des intégrations.

En outre, une technologie d’intégration ne répondra pas forcément à tous les besoins selon la nature synchrone ou asynchrone des échanges ainsi que selon le volume et la fréquence des communications.

Pour déterminer quelles solutions adopter, il est nécessaire de faire l’inventaire des flux avec pour chacun un certains nombre de critères: source, destination, synchrone/asynchrone, fréquence, volume des échanges, nature des données échangées, besoin de reprise après échec, temps de latence acceptable entre l’émission et la réception, besoin de gérer des transactions sur les données, besoin d’orchestrer des flux entre eux, besoin de transformer les données, besoin de faire du transcodage entre les systèmes…

Conclusion

Pour répondre à la question « quelle architecture applicative en 2021? », il est important de prendre en compte tous les éléments ci-dessus. Attention à la tendance naturelle à privilégier les facteurs qui nous sont plus familiers tels que la technologie ou les interfaces utilisateurs par exemple, au détriment des autres éléments essentiels, parfois moins attrayants. Une Architecture Applicative n’a de sens qu’en prenant l’application dans son ensemble, au sein de son écosystème.

Ce travail est souvent plus guidé et rigide dans un grand groupe où les marges de manœuvre sont réduites pour les choix architecturaux des applications. Mais dans les structures moyennes ou plus petites, il est encore possible de définir tous les tenants et aboutissants pour faire les bons choix. Alors à vous de jouer!

Merci pour votre lecture, n’hésitez pas à partager cet article.
Je peux être amené à citer des marques (produits, solutions, entreprises) par choix rédactionnel. Mais sans indication explicite de ma part, cela ne préjuge en rien d’un quelconque partenariat ou placement de produit.
N’hésitez pas à faire part de vos connaissances et expériences pour compléter cette fiche. Utilisez les commentaires mais toujours avec bienveillance et courtoisie 😃. Au plaisir de vous lire.