Ce que fait un architecte : responsabilités, compétences et types d’architectes

À quoi servent les architectes

Si l’architecture est l’ensemble des décisions et des structures significatives d’un système (section 1.1), l’architecte est quiconque veille à ce que ces décisions soient bien prises, comprises par les autres et respectées à mesure que le système évolue. Cela paraît simple, mais c’est l’un des rôles les moins uniformément définis du logiciel. Dans une entreprise, l’architecte est un ingénieur senior qui écrit encore du code tous les jours ; dans une autre, un membre d’une équipe centrale qui revoit les conceptions et tient à jour les normes ; dans une troisième, une personne qui parle surtout avec les dirigeants métier et les fournisseurs.

Derrière cette diversité se trouve un socle commun. Les architectes prennent ou orientent les décisions coûteuses à inverser, veillent aux qualités du système entier plutôt qu’à celles d’une seule partie, et relient les choix techniques aux objectifs métier. La suite de cette section décrit ce que cela implique, les compétences requises et la façon dont le rôle est organisé.

Huit attentes envers un architecte

Mark Richards et Neal Ford, dans Fundamentals of Software Architecture (O’Reilly, 1re édition 2020, 2e édition 2025), décrivent huit attentes essentielles envers un architecte, quels que soient l’intitulé du poste ou l’entreprise. Elles sont paraphrasées ci-dessous, avec pour chacune un exemple tiré d’une entreprise de livraison de repas.

Remarquez combien peu de ces huit attentes sont purement techniques. Richards et Ford soulignent que presque chaque décision d’un architecte sera contestée par quelqu’un (développeurs, autres architectes, product owners, chefs de projet) : la négociation et la persuasion sont donc des compétences essentielles, pas des extras. Une architecture correcte sur le papier mais ni comprise ni acceptée ne sera pas construite comme prévu.

La vision des tâches de l’architecte selon l’iSAQB

L’International Software Architecture Qualification Board (iSAQB), dont le programme de niveau Foundation (CPSA-F) est largement utilisé en Europe, décrit les tâches et responsabilités des architectes de façon similaire. En résumé, les architectes : clarifient et examinent attentivement les exigences et les contraintes ; décident comment décomposer le système en blocs de construction avec leurs dépendances et leurs interfaces ; décident des préoccupations transversales (cross-cutting concerns) comme la persistance, la communication et l’interface utilisateur ; communiquent et documentent l’architecture ; accompagnent sa réalisation et sa mise en œuvre ; l’analysent et l’évaluent, notamment au regard des risques de ne pas satisfaire les exigences ; et expliquent les conséquences des décisions architecturales aux autres parties prenantes.

Le programme souligne aussi que ces tâches sont itératives : les architectes travaillent par cycles, en revenant sur les exigences et les décisions à mesure que les retours arrivent, plutôt que de concevoir une fois pour toutes puis de passer la main. La section 1.8 examine comment cela s’intègre à une livraison itérative et continue.

Types d’architectes

Les intitulés suivent les niveaux d’architecture décrits dans la section 1.2. Les responsabilités exactes varient fortement d’une organisation à l’autre : considérez le tableau ci-dessous comme typique plutôt que définitif.

Un rôle ou un intitulé de poste ?

L’architecture est un ensemble de responsabilités avant d’être un intitulé de poste. Dans de nombreuses organisations, en particulier les plus petites et celles qui sont organisées autour d’équipes produit autonomes, personne ne porte le titre d’« architecte ». Le travail architectural est pourtant fait, par les responsables techniques, les ingénieurs seniors ou l’équipe collectivement. Ce qui compte, c’est que quelqu’un soit clairement responsable des décisions significatives et des qualités à l’échelle du système. Quand personne ne l’est, une architecture est quand même produite, mais par accident.

De nombreuses entreprises technologiques proposent une filière de carrière technique pour les contributeurs individuels seniors, avec des niveaux comme staff engineer et principal engineer. Le livre Staff Engineer (2021) de Will Larson décrit quatre archétypes courants de ces rôles, dont l’un est explicitement appelé l’Architect : une personne responsable de l’orientation et de la qualité d’un domaine technique critique. Les autres (le Tech Lead, le Solver et le Right Hand) assument aussi une part importante de responsabilité architecturale. Dans ces organisations, le travail de l’architecte est fait par des personnes qui sont aussi ingénieurs.

L’article de Martin Fowler de 2003, Who Needs an Architect?, oppose deux caricatures : un architecte qui prend seul toutes les décisions importantes, et un autre qui travaille étroitement avec l’équipe, encadre les développeurs et les aide à prendre eux-mêmes de bonnes décisions. Fowler plaidait résolument pour le second. La plupart des praticiens s’accordent aujourd’hui à dire que les architectes qui dictent à distance tendent à produire des conceptions que les équipes contournent discrètement.

L’étendue technique face à la profondeur

Les développeurs sont généralement récompensés pour leur profondeur : connaître extrêmement bien un langage, un framework ou une plateforme. Les architectes ont besoin d’un profil différent. Richards et Ford décrivent une pyramide de la connaissance à trois niveaux : ce que vous savez (là où vous avez une réelle expertise), ce que vous savez ne pas savoir (vous savez que cela existe et à peu près à quoi cela sert, mais vous ne pourriez pas vous en servir pour construire quelque chose aujourd’hui), et ce que vous ne savez pas que vous ne savez pas. L’expertise du niveau supérieur doit être entretenue, ce qui prend du temps. Le niveau intermédiaire est peu coûteux à développer, et c’est lui qui vous permet de reconnaître les options.

La valeur d’un architecte réside en grande partie dans son étendue technique (technical breadth) : savoir qu’il existe cinq façons de résoudre un problème, ce en quoi chacune est bonne ou mauvaise, et laquelle mérite un examen plus approfondi. Un architecte qui ne connaît qu’une seule base de données la recommandera à chaque fois. L’étendue a un prix, car le temps passé à élargir le niveau intermédiaire n’est pas passé à approfondir le niveau supérieur ; les architectes laissent donc délibérément s’estomper certaines expertises anciennes et investissent dans la connaissance d’un plus grand nombre de choses. Richards et Ford mettent en garde contre l’échec inverse : l’architecte dont les opinions se sont forgées sur une mauvaise expérience vécue il y a des années et qui rejette toute option qui lui ressemble.

Les architectes doivent-ils écrire du code ?

Les praticiens sont réellement en désaccord sur ce point, et ce désaccord est utile, car chaque camp a raison sur quelque chose.

Les arguments pour. Les architectes qui codent comprennent le coût réel de leurs décisions, remarquent quand un principe est pénible en pratique, gardent leur jugement technique à jour et conservent le respect des développeurs qui doivent mettre en œuvre leurs conceptions. Les architectes qui cessent de coder pendant des années risquent de concevoir des systèmes élégants sur un tableau blanc et malcommodes dans un éditeur.

Les arguments contre. Le temps d’un architecte est réparti entre de nombreuses équipes, réunions et décisions. Un architecte responsable de fonctionnalités sur le chemin critique devient un goulot d’étranglement : l’équipe attend du code retardé par ses autres obligations. Son attention est aussi nécessaire sur les préoccupations inter-équipes dont aucune équipe ne s’occupera seule.

La solution courante. La plupart des voix expérimentées, dont Richards et Ford, recommandent que les architectes restent impliqués dans le code d’une manière qui ne les place pas sur le chemin critique. Par exemple : construire une preuve de concept (proof of concept) pour tester une option risquée avant que l’équipe ne s’y engage ; écrire des fonctions d’aptitude (fitness functions), des contrôles automatisés qui vérifient des règles architecturales comme « le module de domaine ne doit pas dépendre du framework web » ; corriger des bugs et traiter de petits éléments de dette technique ; construire des outils et de l’automatisation pour l’équipe ; et relire régulièrement du code, ce qui montre comment les décisions sont réellement mises en œuvre.

import pathlib, re

FORBIDDEN = re.compile(r"^\s*(from|import)\s+flask\b", re.M)

def test_domain_does_not_depend_on_web_framework():
    offenders = []
    for path in pathlib.Path("shop/domain").rglob("*.py"):
        if FORBIDDEN.search(path.read_text(encoding="utf-8")):
            offenders.append(str(path))
    assert not offenders, f"Domain code imports Flask: {offenders}"