Solution Architect : rôle, TOGAF et certifications

Qu'est-ce qu'un Solution Architect ?

Le Solution Architect (architecte de solutions) est un professionnel IT qui conçoit l'architecture technique d'un projet ou d'un produit numérique. Son rôle est de traduire les besoins métier en solutions technologiques cohérentes, scalables et maintenables. Il occupe une position charnière entre les équipes techniques et les décideurs business.

Il ne code pas lui-même (ou rarement), mais il définit comment le code sera structuré, quelles technologies seront choisies, comment les systèmes s'interconnecteront, et comment la solution évoluera dans le temps.

Solution Architect vs Enterprise Architect : quelle différence ?

Ces deux titres sont souvent confondus mais ils n'opèrent pas à la même échelle :

Les quatre domaines d'architecture

Dans le cadre TOGAF, un Enterprise Architect travaille sur quatre couches (ADM — Architecture Development Method) :

• Architecture Business — processus métier, organisation, fonctions
• Architecture Data — modèles de données, flux d'information, MDM
• Architecture Applicative — portefeuille applicatif, interfaces, patterns
• Architecture Technique — infrastructure, cloud, réseaux, sécurité

Le Solution Architect se concentre principalement sur les couches applicative et technique pour un projet donné.

Missions et responsabilités quotidiennes

Les journées d'un Solution Architect sont variées. Voici ses principales missions concrètes :

Réponse aux appels d'offres (RFP)

En ESN ou cabinet de conseil, une part importante du temps est consacrée aux RFP (Request For Proposal) et aux avant-ventes. Le SA analyse le besoin client, rédige la solution technique, estime les charges et présente l'offre. Une bonne réponse à RFP peut représenter plusieurs semaines de travail pour des projets à plusieurs millions d'euros.

// Structure type d'un Document d'Architecture Technique (DAT)
// Ce document est le livrable principal du Solution Architect

DAT — Structure recommandée :
├── 1. Contexte et objectifs du projet
│   ├── Périmètre fonctionnel
│   ├── Contraintes (budget, délais, existant)
│   └── Parties prenantes
├── 2. Architecture cible (High-Level Design)
│   ├── Vue d'ensemble (C4 Level 1 — Contexte)
│   ├── Composants principaux (C4 Level 2 — Container)
│   └── Flux de données principaux
├── 3. Architecture détaillée (Low-Level Design)
│   ├── Diagrammes de séquence (cas d'usage critiques)
│   ├── Modèle de données
│   └── APIs et contrats d'interface
├── 4. Décisions architecturales (ADR)
│   ├── Choix technologiques (avec justification)
│   └── Alternatives rejetées (avec raisons)
├── 5. Sécurité et conformité
│   ├── Classification des données
│   ├── Contrôle d'accès
│   └── Audit trail
├── 6. Performance et scalabilité
│   ├── Objectifs SLA/SLO
│   ├── Stratégie de montée en charge
│   └── Points de contention identifiés
└── 7. Plan de transition et migration
    ├── Big bang vs. migration progressive
    └── Stratégie de rollback

Cartographie du Système d'Information

L'Enterprise Architect maintient une cartographie SI à jour qui représente l'ensemble des applications, leurs interactions et leur positionnement dans les couches du SI. Cet outil est indispensable pour identifier les redondances, les zones de risque (applications obsolètes, "legacy") et planifier la modernisation.

Arbitrages technologiques

Le SA est régulièrement sollicité pour trancher des questions comme :

• Microservices vs monolithe modulaire pour ce nouveau projet ?
• REST vs GraphQL vs gRPC pour cette API ?
• Kubernetes vs serverless pour ce workload ?
• SQL vs NoSQL pour cette volumétrie de données ?

Ces décisions sont documentées dans des ADR (Architecture Decision Records), fichiers Markdown versionnés dans le repo Git de l'équipe :

# ADR-001 : Choix du pattern de communication inter-services

## Statut : Accepté
## Date : 01/05/2026
## Contexte
Notre plateforme e-commerce doit gérer des pics de charge importants
(Black Friday : x10 le trafic nominal). Deux options évaluées :
- API REST synchrone entre microservices
- Messaging asynchrone via Apache Kafka

## Décision
Nous adoptons Apache Kafka pour les flux critiques (commandes, paiements)
et conservons REST pour les appels de lecture (catalogue, recherche).

## Conséquences
+ Découplage fort entre producteurs et consommateurs
+ Résilience aux pannes partielles du système
+ Replay des événements possible (audit, reprise sur incident)
- Complexité opérationnelle accrue (cluster Kafka à maintenir)
- Latence légèrement plus élevée sur les flux asynchrones

## Alternatives rejetées
REST synchrone uniquement : risque de cascade failure si un service
est lent. Inacceptable pour le SLA (99.9% disponibilité).

Accompagnement des équipes de développement

Le SA n'est pas un acteur isolé dans sa tour d'ivoire. Il accompagne les équipes au quotidien : revues de code architecture, sessions de pair-programming sur les patterns complexes, formation aux bonnes pratiques (SOLID, DDD, Clean Architecture), et clarification des ambiguïtés du DAT en cours de sprint.

Compétences techniques requises

Le Solution Architect est le profil le plus polyvalent du secteur IT. Il doit avoir une vision large sans être superficiel sur les sujets critiques.

TOGAF et urbanisation du SI

Le framework TOGAF (The Open Group Architecture Framework) est la référence mondiale pour la gouvernance architecturale d'entreprise. Sa certification (niveau Foundation puis Practitioner) est quasi-incontournable pour les postes d'Enterprise Architect, et très appréciée pour les Solution Architects seniors en grand compte.

// Cycle ADM (Architecture Development Method) — TOGAF
// Chaque phase produit des livrables spécifiques

Phase A : Architecture Vision
  → Livrable : Architecture Vision Document
  → Objectif : Définir la portée, les objectifs, les parties prenantes

Phase B : Business Architecture
  → Livrable : Diagrammes de processus métier (BPMN)
  → Objectif : Modéliser l'organisation et ses fonctions

Phase C : Information Systems Architecture
  C1 - Data Architecture
    → Livrable : Modèle de données conceptuel, Data Flow Diagrams
  C2 - Application Architecture
    → Livrable : Portefeuille applicatif, diagrammes d'intégration

Phase D : Technology Architecture
  → Livrable : Infrastructure blueprint (cloud, réseau, sécurité)
  → Objectif : Décrire les composants technologiques

Phase E : Opportunities & Solutions
  → Livrable : Plan de travaux, roadmap de migration

Phase F : Migration Planning
  → Livrable : Architecture Roadmap avec jalons

Phase G : Implementation Governance
  → Livrable : Contrats d'architecture, reviews régulières

Phase H : Architecture Change Management
  → Livrable : Tableau de bord d'évolution du SI

Maîtrise des patterns cloud et intégration

Le cloud est désormais le socle de toute architecture moderne. Le SA maîtrise les patterns fondamentaux :

• Event-Driven Architecture (EDA) — Kafka, RabbitMQ, AWS EventBridge
• CQRS + Event Sourcing — séparation lecture/écriture pour la scalabilité
• API Gateway + BFF (Backend For Frontend) — pattern d'exposition API
• Circuit Breaker + Retry — résilience des appels inter-services
• Saga pattern — transactions distribuées dans les microservices
• Strangler Fig — migration progressive du legacy vers le moderne

// Exemple : Pattern Circuit Breaker — pseudocode architectural
// Protège le système contre les pannes en cascade

class CircuitBreaker {
  // États possibles : CLOSED (normal), OPEN (coupé), HALF_OPEN (test)
  private state: 'CLOSED' | 'OPEN' | 'HALF_OPEN' = 'CLOSED';
  private failureCount: number = 0;
  private readonly threshold: number = 5; // Seuil avant ouverture
  private lastFailureTime: number = 0;
  private readonly timeout: number = 30000; // 30s avant tentative HALF_OPEN

  async call(service: () => Promise<any>): Promise<any> {
    // Si le circuit est ouvert, on rejette immédiatement
    if (this.state === 'OPEN') {
      const elapsed = Date.now() - this.lastFailureTime;
      if (elapsed < this.timeout) {
        throw new Error('Circuit OPEN — service indisponible');
      }
      // Après timeout, on passe en HALF_OPEN pour tester
      this.state = 'HALF_OPEN';
    }

    try {
      const result = await service();
      // Succès : réinitialise le compteur
      this.onSuccess();
      return result;
    } catch (error) {
      // Échec : incrémente le compteur et évalue l'état
      this.onFailure();
      throw error;
    }
  }

  private onSuccess(): void {
    this.failureCount = 0;
    this.state = 'CLOSED'; // Retour à la normale
  }

  private onFailure(): void {
    this.failureCount++;
    this.lastFailureTime = Date.now();
    // Ouvre le circuit si le seuil est atteint
    if (this.failureCount >= this.threshold) {
      this.state = 'OPEN';
    }
  }
}

Socle technique attendu

Soft skills et qualités relationnelles

Le Solution Architect est avant tout un communicant. Une solution techniquement parfaite mais impossible à défendre en réunion ne sera jamais mise en œuvre. Les soft skills sont aussi déterminants que les compétences techniques.

Communication client-facing

En ESN ou cabinet de conseil, le SA est en contact direct avec des interlocuteurs non-techniques (DSI, directeurs métier, chefs de projet MOA). Il doit :

• Vulgariser : expliquer un pattern microservices à un directeur financier sans jargon
• Visualiser : présenter l'architecture avec des diagrammes compréhensibles (C4, ArchiMate simplifié)
• Convaincre : défendre des choix technologiques face à des résistances budgétaires ou organisationnelles
• Écouter : identifier les besoins implicites derrière une demande formulée techniquement

Négociation et arbitrage

Un SA est constamment en situation de tension : le client veut tout, vite, pour pas cher, et le résultat doit durer 10 ans. Il doit savoir négocier le triangle QCD (Qualité / Coût / Délai) et imposer des compromis réalistes, tout en maintenant la confiance des parties prenantes.

Leadership technique sans autorité hiérarchique

Le SA influence sans commander. Il doit obtenir l'adhésion des équipes de développement sur ses choix architecturaux, souvent via la conviction et la démonstration plutôt que par la hiérarchie. Cette capacité à exercer un leadership d'influence est rare et très valorisée.

Gestion de l'ambiguïté

Les projets complexes sont rarement bien définis au démarrage. Le SA doit être à l'aise avec l'ambiguïté, capable de prendre des décisions architecturales avec des informations incomplètes, tout en documentant les hypothèses prises pour les revisiter plus tard.

Salaires et fourchettes par profil

Le Solution Architect est l'un des profils IT les mieux rémunérés en France. Les salaires varient significativement selon l'expérience, le secteur (ESN, cabinet conseil, entreprise en propre) et la localisation géographique.

Grilles salariales France 2026

Freelance et TJM

Les Solution Architects freelances sont très demandés, notamment en mission dans les grandes banques, assurances et administrations. Les TJM (Taux Journalier Moyen) pratiqués en 2026 :

• SA Junior freelance — 550 à 700 €/jour
• SA Confirmé freelance — 700 à 900 €/jour
• SA Senior freelance — 900 à 1 200 €/jour
• Enterprise Architect freelance — 1 100 à 1 500 €/jour

Comparaison internationale

Évolution de carrière et certifications

Le métier de Solution Architect offre plusieurs trajectoires d'évolution. La progression est généralement plus lente que dans d'autres filières (le titre "Senior SA" s'obtient rarement avant 8-10 ans d'expérience), mais les paliers de rémunération et de responsabilité sont significatifs.

Trajectoires d'évolution

// Trajectoires de carrière — Solution Architect

Développeur Senior (3-5 ans)
        |
        ▼
Solution Architect Junior (2-4 ans expérience totale)
  → Focus : maîtrise d'un domaine (cloud, data, API)
  → Compétences : DAT, HLD/LLD, first client interactions
        |
        ├──────────────────────────────────────────┐
        ▼                                          ▼
SA Confirmé (5-8 ans)                   Lead Architect (5-8 ans)
  → Plusieurs projets en parallèle        → Manage une équipe d'architectes
  → Certifications TOGAF + cloud          → Définit les standards du cabinet
        |
        ├──────────────────────────────────────────┐
        ▼                                          ▼
SA Senior / Principal (8-12 ans)        Enterprise Architect (10+ ans)
  → Architectures complexes              → Cartographie SI entreprise
  → Avant-vente et RFP                   → Schéma directeur 5 ans
  → Mentoring juniors                    → Membre COMEX / DSI adjoint
        |                                          |
        ▼                                          ▼
Chief Architect / CTO                   DSI / VP Architecture
  → Vision technologique globale         → Gouvernance IT
  → Décisions stratégiques               → Budget et investissements IT

Certifications incontournables

SA vs Architecte Logiciel vs Cloud Architect vs CTO

Le titre d'architecte recouvre des réalités très différentes selon les entreprises. Voici une grille de lecture pour ne plus confondre ces rôles complémentaires :

Frontières floues selon les entreprises

Dans une start-up de 20 personnes, le CTO fait le travail du SA, de l'Enterprise Architect et du Cloud Architect. Dans une grande banque, ces quatre rôles sont des équipes entières avec des dizaines de personnes.

En ESN comme Capgemini, Sopra Steria, Atos ou Accenture, le titre "Solution Architect" désigne souvent quelqu'un qui a 5-10 ans d'expérience et intervient en avant-vente + delivery. Dans les Big 4 du conseil (Deloitte, PWC, KPMG, EY), le même profil s'appellera "Manager" ou "Senior Manager" de la practice Architecture.

Comment devenir Solution Architect ?

Il n'existe pas de formation directe vers le métier de Solution Architect. Ce rôle s'acquiert par l'expérience terrain, progressivement, en passant par des postes techniques intermédiaires.

Parcours recommandé étape par étape

// Parcours type vers Solution Architect — 8 à 12 ans

ÉTAPE 1 : Développeur (0-3 ans)
  - Objectif : maîtriser au moins un langage (Java, Python, TypeScript)
  - Apprendre les design patterns (GoF, SOLID, Clean Code)
  - Contribuer à des projets réels, lire du code existant
  - Outils : Git, Docker, IDE, SQL

ÉTAPE 2 : Développeur Senior / Tech Lead (3-6 ans)
  - Objectif : avoir une vision système au-delà d'une feature
  - Mener des code reviews, écrire des specs techniques
  - Premiers contacts avec les décisions d'architecture
  - Certifications : AWS Associate, Docker Certified Associate
  - Participer aux réunions client, comprendre les enjeux métier

ÉTAPE 3 : Architecte Junior / Solution Architect Confirmé (6-9 ans)
  - Objectif : prendre en charge des projets de bout en bout
  - Rédiger des DAT, présenter des architectures à des comités
  - Certifications : TOGAF Foundation + Practitioner
  - Développer son réseau dans les communautés tech (meetups, confs)
  - Certification cloud avancée (AWS Professional ou équivalent)

ÉTAPE 4 : Solution Architect Senior (9-12 ans)
  - Objectif : être la référence technique sur son domaine
  - Animer des avant-ventes, répondre à des RFP complexes
  - Mentorer des architectes juniors
  - Publications techniques (blog, conférences, white papers)
  - Construire une expertise verticale (finance, e-commerce, santé, etc.)

ÉTAPE 5 : Enterprise Architect / Principal Architect (12+ ans)
  - Objectif : vision stratégique sur l'ensemble du SI
  - Travaux de schéma directeur, gouvernance TOGAF
  - Interactions avec le COMEX et le board
  - Certifications avancées : TOGAF 10, IASA CITA-P/F

Formations et ressources recommandées

• "Designing Data-Intensive Applications" (Martin Kleppmann) — bible de l'architecture data moderne
• "Clean Architecture" (Robert C. Martin) — fondamentaux de l'architecture applicative
• "Building Microservices" (Sam Newman) — référence sur les architectures microservices
• "Enterprise Integration Patterns" (Gregor Hohpe) — patterns d'intégration SI classiques
• AWS Skill Builder, Google Cloud Skills Boost — plateformes officielles de formation cloud
• The Open Group TOGAF Study Guide — préparation officielle à la certification
• Architecture Weekly (Oskar Dudycz) — newsletter hebdomadaire de référence

Outils et environnement de travail

Le Solution Architect travaille avec un ensemble d'outils variés selon les phases du projet et les exigences du client.

Outils de modélisation architecturale

Diagramme as-code avec PlantUML

La tendance "Architecture as Code" permet de versionner les diagrammes dans Git et de les générer automatiquement dans les pipelines CI/CD :

@startuml
' Diagramme C4 Level 2 — Système de commandes e-commerce
' PlantUML permet de versionner les diagrammes dans Git

!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

title Conteneurs — Plateforme E-Commerce

Person(customer, "Client", "Passe des commandes en ligne")
Person(admin, "Administrateur", "Gère le catalogue et les commandes")

System_Boundary(ecommerce, "Plateforme E-Commerce") {
    Container(spa, "Single Page App", "Angular 17", "Interface client responsive")
    Container(api_gateway, "API Gateway", "AWS API Gateway", "Point d'entrée unique, auth JWT")
    Container(order_service, "Order Service", "Node.js / Express", "Gestion des commandes")
    Container(payment_service, "Payment Service", "Java / Spring Boot", "Intégration Stripe/PayPal")
    Container(catalog_service, "Catalog Service", "Python / FastAPI", "Produits et stocks")
    ContainerDb(order_db, "Orders DB", "PostgreSQL", "Commandes et historique")
    ContainerDb(catalog_db, "Catalog DB", "MongoDB", "Produits et catalogue")
    Container(event_bus, "Event Bus", "Apache Kafka", "Orchestration async des événements")
}

System_Ext(payment_gw, "Stripe", "Paiement en ligne")
System_Ext(email_service, "SendGrid", "Envoi d'emails transactionnels")

' Relations
Rel(customer, spa, "Utilise", "HTTPS")
Rel(admin, spa, "Administre", "HTTPS")
Rel(spa, api_gateway, "Appelle", "HTTPS/REST")
Rel(api_gateway, order_service, "Route", "HTTP interne")
Rel(api_gateway, catalog_service, "Route", "HTTP interne")
Rel(order_service, order_db, "Lit/Écrit", "JDBC")
Rel(order_service, event_bus, "Publie OrderCreated", "Kafka")
Rel(event_bus, payment_service, "Consomme OrderCreated", "Kafka")
Rel(payment_service, payment_gw, "Appelle", "HTTPS")
Rel(payment_service, event_bus, "Publie PaymentConfirmed", "Kafka")
Rel(event_bus, email_service, "Notifie le client", "HTTPS")
Rel(catalog_service, catalog_db, "Lit/Écrit", "MongoDB Driver")
@enduml

Gestion de la documentation — Confluence et ADO

La documentation architecturale vit dans Confluence (Atlassian) ou Azure DevOps Wiki. Le SA maintient :

• Les ADR (Architecture Decision Records) versionnés dans Git (format MADR ou NAT)
• Le repository de principes d'architecture (règles que tous les projets doivent respecter)
• La cartographie applicative (mise à jour trimestrielle)
• Les patterns approuvés (golden paths) que les équipes peuvent réutiliser

Tendances et futur du métier

Le métier de Solution Architect évolue rapidement sous l'impulsion de plusieurs transformations technologiques majeures.

Cloud-Native et Platform Engineering

L'adoption massive de Kubernetes et des architectures cloud-native redéfinit le rôle du SA. Il doit désormais maîtriser les Internal Developer Platforms (IDP), les concepts de GitOps et les pratiques FinOps (optimisation des coûts cloud). Le SA collabore étroitement avec les Platform Engineers pour définir les "golden paths" que les équipes produit vont emprunter.

// Architecture cloud-native typique 2026
// Le SA définit les standards, les Platform Engineers les implémentent

Architecture Cloud-Native référence :

┌─────────────────────────────────────────────────────────────┐
│                    Internal Developer Platform              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐  │
│  │  Backstage   │  │   Argo CD    │  │  Service Mesh    │  │
│  │  (portail    │  │  (GitOps     │  │  (Istio / Linkerd│  │
│  │  dev)        │  │  deploy)     │  │  mTLS, observ.)  │  │
│  └──────────────┘  └──────────────┘  └──────────────────┘  │
└─────────────────────────────────────────────────────────────┘
             │                   │
             ▼                   ▼
┌────────────────────┐  ┌──────────────────────────────────┐
│  Observabilité     │  │  Kubernetes (EKS / GKE / AKS)   │
│  - Prometheus      │  │  ┌──────────┐  ┌──────────────┐  │
│  - Grafana         │  │  │ namespace│  │  namespace   │  │
│  - Jaeger (traces) │  │  │ team-a   │  │  team-b      │  │
│  - Loki (logs)     │  │  └──────────┘  └──────────────┘  │
└────────────────────┘  └──────────────────────────────────┘
             │
             ▼
┌────────────────────────────────────────────────────────┐
│  FinOps — Kubecost + AWS Cost Explorer                 │
│  Objectif : coût par équipe produit visible en temps réel │
└────────────────────────────────────────────────────────┘

IA générative dans l'architecture

L'émergence des LLM (GPT-4, Gemini, Claude) transforme déjà la pratique architecturale :

• Génération automatique de diagrammes depuis des descriptions en langage naturel (GitHub Copilot, Structurizr AI)
• Analyse de code existant pour produire des cartographies applicatives semi-automatiques
• Chatbot d'architecture interrogeable sur les patterns, les ADR et les décisions passées
• Revue automatisée de DAT pour détecter les incohérences et les oublis

Architecture événementielle et DDD

Le Domain-Driven Design (DDD) et l'Event-Driven Architecture (EDA) s'imposent comme les paradigmes de référence pour les systèmes distribués complexes. Les SA qui maîtrisent l'Event Storming (atelier de découverte des domaines) et la modélisation des Bounded Contexts sont particulièrement recherchés dans les grandes transformations digitales.

// Modélisation DDD — Bounded Contexts d'une plateforme e-commerce
// L'Event Storming identifie les domaines, le SA structure les contexts

Bounded Context : Order Management
  Aggregate : Order
    - OrderId (Value Object)
    - CustomerId (Value Object)
    - OrderItems : List<OrderItem>
    - Status : OrderStatus (enum)
    - Events émis :
      → OrderPlaced
      → OrderConfirmed
      → OrderShipped
      → OrderDelivered
      → OrderCancelled

Bounded Context : Inventory Management
  Aggregate : Product
    - ProductId (Value Object)
    - Stock : StockLevel
    - Events émis :
      → StockReserved
      → StockReleased
      → LowStockAlert

Bounded Context : Payment
  Aggregate : Payment
    - PaymentId (Value Object)
    - Amount : Money (Value Object)
    - Status : PaymentStatus
    - Events émis :
      → PaymentInitiated
      → PaymentAuthorized
      → PaymentFailed
      → RefundProcessed

// Communication inter-contexts : via Event Bus (Kafka)
// PAS d'appels synchrones directs entre les aggregates
// Chaque context est autonome et déployable indépendamment

Sustainability Architecture

La dimension environnementale devient un critère architectural à part entière. Les organisations grandes et petites intègrent la Green IT dans leurs principes architecturaux : choix de régions cloud les moins énergivores, optimisation des workloads pour réduire l'empreinte carbone, architecture "demand shaping" pour lisser les pics de charge. Le SA de 2026 doit connaître les outils comme AWS Customer Carbon Footprint Tool ou Google Cloud Carbon Footprint.

Conclusion

Le Solution Architect est l'un des métiers les plus exigeants et les plus valorisants de l'écosystème IT. Il combine une technicité pointue, une vision systémique, des qualités relationnelles fortes et une capacité à naviguer dans des environnements organisationnels complexes.

La progression vers ce rôle requiert de la patience — on n'est pas Solution Architect à 25 ans sans exception — mais le chemin est balisé : commencer par maîtriser la technique, élargir sa vision progressive, obtenir les certifications TOGAF et cloud, et cultiver sa capacité à communiquer avec des non-techniciens. Les opportunités sont nombreuses en France, avec une demande soutenue dans les secteurs Banque, Assurance, Télécoms et e-commerce, et des rémunérations parmi les plus élevées du secteur.

Ressources pour aller plus loin

• The Open Group — TOGAF officiel
• C4 Model — Simon Brown
• Structurizr — C4 as-code
• Martin Fowler — Architecture Blog
• AWS Architecture Center — Well-Architected Framework
• IASA — International Association of Software Architects