L’Architecte Solutions décide comment transformer des contraintes métier, techniques, financières et réglementaires en une architecture réalisable — puis en une trajectoire que les équipes peuvent effectivement suivre.
L’Architecte Solutions ne se contente pas de produire un schéma cible. Il détermine comment une solution applicative s’insère dans un système existant : services, données, réseau, identités, infrastructure, exploitation, sécurité et contraintes contractuelles. Il doit comprendre suffisamment chaque registre pour repérer les dépendances structurantes, sans se substituer aux spécialistes qui les mettent en œuvre.
La différence entre celui qui décrit une architecture et celui qui tient réellement le poste apparaît dans la trajectoire. Une cible techniquement cohérente peut rester inutilisable si elle suppose une migration globale, des compétences absentes, une rupture impossible à absorber ou un coût d’exploitation que personne n’a accepté.
Le métier se situe au croisement de tensions permanentes : standardisation contre autonomie des équipes, résilience contre complexité, service managé contre dépendance fournisseur, modernisation contre continuité. L’évaluation cherche moins à savoir si le candidat connaît un pattern qu’à observer comment il qualifie ces tensions, choisit ce qu’il protège et nomme ce qu’il accepte de dégrader.
Repères marché
Le marché regroupe des intitulés très hétérogènes : Architecte Solutions, Architecte Cloud, Solution Architect, Architecte Technique ou Architecte Applicatif peuvent désigner des périmètres proches ou très différents. La demande reste soutenue dans les organisations qui modernisent leur système d’information ou développent des plateformes distribuées.
Les profils réellement séniors sont rares, car ils doivent combiner une profondeur technique suffisante, une capacité d’arbitrage et une influence transverse. Une partie importante du vivier travaille en conseil ou en indépendant, ce qui renforce l’enjeu d’évaluer la capacité à s’inscrire durablement dans une organisation.
Contexte
En ESN, l’Architecte Solutions intervient souvent sur un patrimoine qu’il n’a pas choisi, auprès de plusieurs donneurs d’ordre et dans un cadre contractuel qui peut figer le périmètre, la date ou le niveau de service. L’évaluation insiste alors sur la capacité à instruire rapidement l’existant, rendre les engagements défendables et proposer une trajectoire compatible avec la relation client.
Niveau 1
Junior
Il décrit une solution cohérente sur son registre d’origine, mais raisonne encore principalement par technologie ou par conformité à une cible. Il peut appliquer une norme ou proposer une architecture sans mesurer les dépendances, les conditions d’exploitation et le chemin nécessaire pour l’adopter.
Cliquer pour lire
Niveau 2
Confirmé
Il conçoit de manière autonome sur un périmètre courant. Il identifie plusieurs options, rend ses hypothèses explicites et couvre les principaux impacts applicatifs, infrastructure, réseau et données. Il sait défendre une architecture, mais peut encore sous-estimer le coût de transition ou traiter des contraintes hétérogènes comme un problème uniforme.
Cliquer pour lire
Niveau 3
Sénior
Il ne sépare plus la cible de sa trajectoire. Il priorise les risques, distingue les besoins réellement différents, anticipe la cohabitation avec l’existant et intègre les compétences disponibles, l’exploitation, la sécurité, les coûts et la réversibilité. Il sait contredire une demande, un pair ou une direction sans transformer le désaccord en conflit d’autorité.
Cliquer pour lire
Niveau 4
Expert
Il n’est pas celui qui connaît davantage de technologies. Il est celui qui tranche lorsque toutes les options ont un coût. Il peut accepter une dette temporaire, une double exploitation, une expérience moins immédiate ou un périmètre plus étroit afin de préserver une trajectoire crédible. Il nomme publiquement ce qui sera perdu et transforme la décision en principe réutilisable par l’organisation.
Cliquer pour lire
L’architecture applicative et le découpage pèsent le plus lourd, car une solution mal découpée crée des dépendances que l’infrastructure seule ne pourra pas compenser. Cette répartition oblige à vérifier que le candidat sait relier les registres plutôt que surdimensionner celui qu’il maîtrise le mieux.
Une solution n’est pas robuste parce qu’elle comporte plusieurs zones ou plusieurs instances : elle l’est lorsque les modes de panne, les besoins de fraîcheur et la cohérence des données ont été explicitement décidés.
Cette catégorie distingue une architecture projetable d’une architecture exécutable. Elle mesure la capacité à séquencer, à vivre avec deux mondes pendant une période donnée et à intégrer le coût total.
Sur ce poste, une exigence contractuelle ou réglementaire ne peut pas rester une mention documentaire : elle doit être traduite en cloisonnement, en contrôle d’accès ou en garde-fou technique.
Une architecture que personne ne comprend, ne finance ou n’applique n’a aucune valeur opérationnelle. Cette catégorie vérifie la capacité à obtenir l’adhésion sans diluer la décision.
La méthode en action
La scorecard en un regard — survoler un axe
Architecture et intégration