Qu’est-ce qu’une architecture logicielle ?

L’architecture d’un logiciel décrit la manière dont seront agencés les différents éléments d’une application et comment ils interagissent entre eux. Cette étape est donc l’une des premières étapes du développement logiciel et intervient lors de la phase de conception. Elle est généralement réalisée par un architecte logiciel ou un architecte solution, élément central du projet de développement.

Dans cet article, nous verrons :

1. L’importance de l’architecture lors d’un développement de logiciel
2. De ce point de vue-là, vers quelle architecture logicielle s’orienter ?
3. Qu’est-ce qui fait une bonne architecture logicielle ?

L’importance de l’architecture lors d’un développement de logiciel :

La conception de l’architecture est une phase particulièrement importante du développement d’un logiciel. Elle conditionne sa stabilité, son efficacité et sa pérennité. Au contraire, certaines applications peuvent connaitre des faiblesses dues à une architecture mal pensée, pas ou plus adaptée au contexte.

Si la pression du time-to-market pèse sur le développement d’un logiciel, elle pèse donc également sur la conception de son architecture. Sachez tout de même qu’une fois le projet commencé, s’agissant d’un élément aussi structurel, il est dangereux voire impossible d’en changer.

Cela étant dit, il n’est pas si fréquent de trouver de « mauvaises » architectures dans l’absolu, mais on observe souvent des architectures qui ne sont pas parfaitement adaptées au contexte du projet de développement. Car l’architecture logicielle est avant tout issue d’un compromis entre les exigences techniques, opérationnelles et fonctionnelles qui entourent l’application. Et c’est là où l’architecte logiciel devra exercer son savoir-faire et disposer d’expériences suffisantes.

De ce point de vue-là, vers quelle architecture logicielle s’orienter ?

Plusieurs critères guident le choix de l’architecture applicative

Tout d’abord, ce choix fait suite à la bonne compréhension du besoin métier et des contraintes fonctionnelles et non fonctionnelles du logiciel.

La compréhension du besoin métier doit par exemple couvrir les différents types d’utilisateurs impliqués, leur(s) différent(s) mode(s) d’accès à ce logiciel.

Les contraintes non fonctionnelles comprennent par exemple les aspects :

• De performance
• De sécurité
• Mais également les contraintes d’exécution et d’exploitation : incluant
  • les plates-formes visées côté client et serveur.
  • l’hébergement attendu : Cloud privé et/ou public, OnPremise ou alors un hébergement hybride, qui est aujourd’hui plus populaire.
  • les systèmes d’exploitation.
  • le choix des technologies : certains choix architecturaux sont couplés à leur environnement d’exécution comme cela peut-être le cas avec le Serverless. A l’inverse, une architecture Microservices se veut agnostique quant aux technologies utilisées.
  • le besoin de résilience du système.
  • la typologie matérielle des écrans. En particulier, la taille des écrans pour utiliser l’application – encore appelé ‘form factor’ – impacte la conception de l’IHM.

Un contexte à prendre en compte

Cette réflexion doit permettre de répondre entre autres à deux questions essentielles en matière d’architecture logicielle : Est-ce que le logiciel doit répondre rapidement ? Quel volume de données doit-il traiter ? Mais permet également se savoir si ces données doivent-elles être centralisées ou réparties ? Comment les utilisateurs doivent-il accéder à l’application du point de vue du réseau ? Sur quel type de matériel ? En quelle langue ou avec quel type de clavier ?

L’architecture du logiciel dépendra ainsi de la typologie de l’entreprise et de l’utilisation à laquelle elle destine le logiciel. Pour prendre un exemple concret, si un éditeur de logiciel se doit d’être flexible afin de répondre à des besoins très différents, le client final souhaite quant à lui un logiciel adapté uniquement au besoin qu’il a pu exprimer.

De même, il est difficile d’atteindre un temps de réponse très rapide lorsque le volume de données traitées est très important ; l’architecture va avoir un impact déterminant pour obtenir un résultat acceptable, et notamment la manière de les organiser, les répartir et les indexer.

Le nombre d’utilisateurs prévu de l’application rentre également en jeu notamment car cela impacte la fréquence des requêtes du logiciel. Un logiciel sollicité chaque jour par 3 utilisateurs sera pensé différemment d’un logiciel sollicité chaque jour par 50 000 utilisateurs, même si le volume de données traitées à chaque requête est faible et similaire.

Le choix de l’architecture peut se faire également en fonction d’éléments externes au projet et notamment les compétences de l’équipe technique qui peuvent orienter vers l’une ou l’autre architecture. Attention tout de même, faute de ressources, de s’orienter vers une architecture peu adaptée au risque de créer des difficultés par la suite. Il existe la possibilité de demander conseil auprès de spécialistes pour mettre en place ou valider une architecture. Découvrez comment SoftFluent peut vous accompagner dans la définition et la conception d’une architecture logicielle. 

Qu’est-ce qui fait une bonne architecture logicielle ?

Une bonne architecture, se définit par :

– Son évolutivité :

L’architecture doit prendre en compte les évolutions futures du logiciel en fonction du besoin métier. Si on ne peut anticiper les évolutions elles-mêmes, elle doit dans ce cas être assez souple pour qu’elles soient possibles, sans tomber dans le piège de vouloir prévoir démesurément le futur.

– Sa simplicité :

Une architecture complexe est souvent source de défaillance et peut créer de la dette technique, impacter les performances ou l’évolutivité d’une application. Elle est due à une mauvaise conception, une sur-ingénierie initiale ou à l’inverse un manque de conception global qui induit une complexification progressive du logiciel dans le temps.

De plus, le logiciel doit avoir une architecture « compréhensible » pour faciliter sa prise en main. Pour cela, il est nécessaire de :

respecter les standards afin qu’il soit possible pour une personne ne connaissant pas le projet d’intervenir.

« Il ne faut pas réinventer des nouvelles organisations mais rester sur des organisations connues. Lorsque les équipes tournent, cela assure la pérennité du logiciel. » – David Rouillon, Architecte chez SoftFluent

documenter l’architecture elle-même.

– Sa maintenabilité :

Une bonne architecture intègre aussi l’outillage nécessaire à sa maintenance. Cela permet notamment de récupérer de l’information de manière centralisée lorsqu’il y a une erreur afin de pouvoir la traiter efficacement et d’agir en conséquence.

– Sa compatibilité :

L’architecture doit définir le compatibilité du logiciel avec les différentes plates-formes matérielles, systèmes d’exploitation, navigateur ou taille d’écran qui conviennent à la cible d’utilisation.

– Son interconnectivité :

Puisque le logiciel évolue dans un certain environnement, son architecture doit permettre son interconnectivité avec d’autres systèmes d’information. Il est de plus en plus rare de trouver un logiciel totalement isolé des autres applications et ne nécessitant pas des interfaces de données ou a minima des exports.

L’architecture logicielle n’a pas de durée de vie à proprement parler.

Ce sont principalement les évolutions de l’application qui vont influer sur son bon fonctionnement. Or, lorsque les besoins métiers ont évolués fortement durant le cycle de vie d’un logiciel, cela peut se traduire par une inadéquation entre l’architecture initiale et les contraintes actuelles ; concrètement, le logiciel risque de ne plus savoir gérer les requêtes. Cela arrive lorsque les nouvelles fonctionnalités se multiplient, la volumétrie de données traitées ‘explose’, etc.

D’où l’importance d’avoir une architecture évolutive. Chez SoftFluent, nous avons pour cela développé un produit de génie logiciel, SoftFluent Code Modeler, qui permet de décorréler la conception fonctionnelle du code, ce qui aide grandement l’évolutivité des applications conçues et leur permet de suivre les technologies pour un coût minimal, par re-génération des couches logicielles métier et accès aux données.

Que ce soit une obsolescence technologique, la fin de support d’une couche logicielle critique, ou tout simplement de nouveaux besoins fonctionnels ou d’intégration, une architecture a toujours une durée de vie limitée.

Finalement, lorsque l’architecture n’est plus adaptée, c’est là que peut intervenir une refonte logicielle qui prendra en compte les nouvelles contraintes.