Fondements de l’ingénierie logicielle

À travers ce module, nous poserons les fondations de l’ingénierie logicielle : un vocabulaire commun pour passer du besoin à une solution construisible. Il y sera présenté la conception d’applications (le comment détaillé), l’architecture (la charpente d’ensemble et ses décisions structurantes) et la chronologie type d’un projet (de la planification à l’exploitation). Il s’agit d’un aperçu de l’ingénierie logicielle : nous ne couvrirons pas toutes les technologies mentionnées, mais l’objectif est de vous y situer et de vous donner des repères solides pour la suite de vos apprentissages.

1) Notion de conception d’applications

Le but : transformer les besoins en une solution détaillée prête à construire.

• Organisation interne des modules/composants, contrats d’API, gestion des erreurs, modèle de données et règles métier, flux UI/UX.
• Choix de patrons (Observer, Strategy, Adapter…), de tactiques (cache, pagination, idempotence) et de contraintes (validation, sécurité, performance).

La portée (vs architecture)

• Architecture = charpente globale (frontières, styles d’intégration, décisions coûteuses à changer).
• Conception = comment réaliser une capacité dans ce cadre (algorithmes, signatures, schémas, tests).

Artefacts typiques

• UML (classes, séquence, états), schémas de données, contrats API (OpenAPI/GraphQL), maquettes UI, règles de validation, tests d’acceptation.

2) Notion d’architecture logicielle

Le but : définir la structure d’ensemble, les relations et les principes qui guident la conception et l’évolution.

Un peu comme pour le bâtiment où l’on fixe d’abord fondations et ossature, l’architecture logicielle regroupe les décisions précoces (frontières, styles, interactions) qui orientent durablement le système ; et ce même si le développement moderne privilégie l’adaptabilité plutôt qu’une planification rigide, ces choix initiaux restent parfois coûteux à modifier.

• Elle décrit les structures, leurs éléments et les relations entre éléments.
• Elle se concentre sur les aspects publics (interfaces, contrats, protocoles) et la façon d’interagir — pas sur chaque détail d’implémentation interne.
• Elle capture surtout les décisions importantes qui façonnent la qualité, la longévité et l’utilité du système.

La tentation est de coder tout de suite ; pourtant, l’architecture pose les fondations : elle concentre des décisions précoces qui orientent tout le reste et conditionnent les qualités du système. Et comme tout logiciel a une architecture (explicite ou non), plus le système est vaste ou complexe, plus une architecture pensée augmente les chances de succès.

Il existe une variété de parties prenantes dans un système logiciel, telles que : les utilisateurs finaux du système, les analystes commerciaux, les experts du domaine, le personnel d’assurance qualité, les gestionnaires, ceux qui peuvent s’intégrer au système et les membres du personnel des opérations.

• Les utilisateurs finaux (indirectement, via les qualités perçues)
• Les analystes commerciaux (traçabilité besoins ↔ solution)
• Les experts métier (règles et périmètre)
• Le personnel d’assurance qualité (développeurs & QA) (contrats, dépendances, tests)
• Ops / sécurité (déploiement, observabilité, conformité)
• Intégrateurs / équipes voisines (interfaces et frontières)
• Gestionnaires (projet/produit/technique) (priorisation, budget, risques, jalons)

Chacune de ces parties prenantes est affectée dans une certaine mesure par l’architecture logicielle. Alors que certaines parties prenantes auront accès et seront intéressées par l’examen de l’architecture logicielle et de sa documentation, d’autres non.

Certaines de ces parties prenantes sont des consommatrices indirectes de l’architecture dans la mesure où elles se soucient du logiciel, et comme l’architecture logicielle est le fondement du système, elles deviennent des consommateurs indirects de l’architecture.

Lorsque nous discutons des consommateurs d’une architecture logicielle, nous ne pouvons pas omettre les développeurs qui travaillent sur ce logiciel. En tant qu’architecte logiciel, il est indispensable de penser à vos développeurs, dont le travail est directement affecté par l’architecture logicielle. Ce sont eux qui travailleront quotidiennement sur le logiciel.

Alors, maintenant que nous savons ce qu’est l’architecture logicielle, son importance et ses avantages, et que nous comprenons qu’il existe une variété de parties prenantes qui en sont affectées, examinons le rôle de l’architecte logiciel.

L’architecte logiciel est la personne qui porte les décisions structurantes du système, aligne les parties prenantes sur les qualités visées et documente les compromis pour guider l’évolution.

Il arrive qu’un projet se fasse sans architecte désigné : le succès ou l’échec peut alors tenir à d’autres facteurs. Lorsque personne ne reçoit spécifiquement le titre d’architecte logiciel, un membre de l’équipe endosse souvent de fait les décisions d’architecture (on parle d’architecte accidentel) ou alors ces décisions émergent collectivement entre développeurs. Enfin, sur des projets plus vastes ou complexes, mieux vaut désigner explicitement ce rôle pour assurer cohérence et gestion des risques.

À retenir

L’architecture logicielle est la structure ou les structures d’un système, leurs éléments et les relations entre ces éléments. C’est une abstraction d’un système logiciel. L’architecture logicielle est importante, car tous les systèmes logiciels ont une architecture, et cette architecture est la base du système logiciel. L’architecture logicielle offre un certain nombre d’avantages, tels que l’activation et l’inhibition des attributs de qualité, vous permettant de prédire les qualités du système logiciel, facilitant la communication avec les parties prenantes et vous permettant d’apporter plus facilement des modifications. Il fournit également un modèle réutilisable qui pourrait être utilisé dans plusieurs produits logiciels, impose des contraintes de mise en œuvre qui réduisent la complexité et minimisent les erreurs des développeurs, améliorent les estimations des coûts/efforts et servent de formation aux nouveaux membres de l’équipe. Les architectes logiciels sont des leaders techniques qui sont ultimement responsables des décisions techniques, de l’architecture et de sa documentation. Ils exécutent un certain nombre de tâches et sont censés avoir des connaissances sur une variété de sujets, à la fois techniques et non techniques.

3) Chronologie de développement d’un système

Analyse, modélisation et conception — repères rapides