Par Aurore Delessert, étudiante en génie électrique à la HEIG-VD et ambassadrice du domaine ingénierie et architecture
Au début de mes études, en cours d'informatique, nous nous lancions directement dans le code. Pas de schéma, pas de plan, juste un fichier vide et l'envie de faire tourner quelque chose. Et ça marchait… jusqu'à ce que ça ne marche plus. Le code devenait trop imposant et la vue d'ensemble de plus en plus difficile à saisir. C'est là qu'intervient l'architecture logicielle.
Dans « architecture logicielle », il y a le mot architecture. Quand nous construisons une maison, personne ne pose la première brique sans avoir des plans détaillés en main. Les architectes, les ingénieur·s et les corps de métier travaillent à partir du même document avant même qu'un seul outil ne soit sorti.
C'est exactement le principe de l'architecture logicielle : c'est la phase de réflexion qui précède l'écriture du code. Elle répond à des questions simples mais essentielles. Quelles sont les grandes parties de mon programme ? Comment communiquent-elles entre elles ? Qui fait quoi ?
Pourquoi avons-nous tendance à zapper cette étape ? L'envie de coder tout de suite est normale, c'est la partie fun, créative, visible. La conception, elle, semble abstraite et nous nous disons parfois « au pire nous pouvons facilement changer le code si ça ne fonctionne pas, pas besoin de plan ». Pourtant, une heure investie dans la réflexion architecturale permet souvent d’éviter plusieurs heures de correction, d’ajustements ou de réécriture. Mais nous ne nous en rendons pas compte car le code n’est pas physique.
En entreprise, un code mal structuré devient rapidement difficile à maintenir lorsque d’autres personnes rejoignent le projet. L'architecture, c'est aussi un langage commun entre les membres d'une équipe.
C'est là qu'entre en jeu UML (Unified Modeling Language), un ensemble de schémas standardisés pour représenter visuellement un logiciel. Ce n'est pas un langage de programmation, c'est un outil de réflexion et de communication, qui s'utilise d'ailleurs bien au-delà du seul domaine du code.
Parmi les diagrammes les plus courants : le diagramme de classes, qui montre les objets du programme et leurs relations ; le diagramme de séquence, qui illustre les échanges entre composants dans le temps ; et le diagramme de cas d'usage, qui décrit les interactions possibles avec le logiciel ainsi que les différents profils d’utilisation.
Ces schémas ne sont pas réservés aux expert·es. Au contraire, ils sont particulièrement utiles quand nous débutons, parce qu'ils nous forcent à clarifier nos idées avant de nous lancer.
Pas besoin d'un outil complexe pour commencer : une feuille blanche, quelques rectangles et quelques flèches suffisent pour nous faire une première idée de là où nous voulons aller.
La prochaine fois que tu te lances dans un projet, même petit, essaie de dessiner d'abord. Tu verras : les bonnes questions émergent bien plus vite avec un crayon qu'avec un clavier.
Si tu t'intéresses aux domaines techniques, suis-nous sur Instagram pour découvrir des projets passionnants.