Quelle architecture logicielle pour son application ?

Brouillon

À venir

0 commentaire

network-1246209_1920

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.

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 peuvent guider le choix de l’architecture logicielle.

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 performance, sécurité, mais également les contraintes d’exécution et d’exploitation, incluant les plates-formes visées côté client et serveur, les systèmes d’exploitation ou 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. 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 ?

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.

Architecture logicielle : caractéristiques

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.

SoftFluent est une société de développement informatique créée 2005 et certifiée Microsoft Gold Partner, Nous vous accompagnons tout le long de votre projet de votre logiciel sur mesure afin de répondre au mieux aux besoins de votre entreprise et d'en garantir le succès.

Forte de son expérience terrain , nous pouvons répondre à vos besoins en matière de conception ou de validation d’architecture logicielle.

Pour en savoir plus, contactez-nous. 

Florine GIllebert

Profil de l'auteur