Il décide comment faire évoluer les socles systèmes, identités, réseaux et services d’infrastructure sans compromettre la continuité d’activité, la sécurité ni la capacité future de l’organisation à les exploiter.
L’Architecte technique infrastructure ne se résume pas à un administrateur Windows, Linux ou Active Directory devenu plus expérimenté. Son périmètre commence précisément là où les expertises spécialisées ne suffisent plus : lorsqu’une décision sur l’annuaire modifie les accès aux applications, lorsqu’une évolution réseau remet en cause la stratégie de sauvegarde, ou lorsqu’une migration techniquement souhaitable devient irréaliste au regard du patrimoine existant.
Le poste consiste à rendre cohérent un ensemble rarement homogène : systèmes Windows Server et Linux, annuaires et fédérations d’identité, DNS, réseaux, virtualisation, stockage, sauvegardes, supervision et parfois infrastructures cloud ou hébergées. La technologie donne le contexte, mais elle n’est pas le critère : l’évaluation observe s’il sait décider où standardiser, où tolérer une exception, quoi migrer et comment réduire un risque sans interrompre les services.
La différence entre l’exécutant expérimenté et celui qui tient réellement le poste apparaît dans les dépendances qu’il prend en compte. Une architecture techniquement propre peut être inexploitable par l’équipe en place ou impossible à migrer dans les fenêtres disponibles. Le métier se joue dans cette tension permanente entre cohérence, sécurité, disponibilité, coût, compétences disponibles et réversibilité.
Repères marché
Le marché français compte de nombreux ingénieurs systèmes ou spécialistes d’un écosystème, mais les profils capables de raisonner transversalement sur Windows, Linux, identité, réseau, stockage, sécurité et continuité sont nettement plus rares. La tension est particulièrement forte sur les environnements hybrides et les patrimoines anciens qui doivent évoluer sans interruption majeure.
Les intitulés sont par ailleurs peu homogènes : Architecte infrastructure, Architecte technique, Architecte systèmes ou Architecte plateformes peuvent désigner des responsabilités proches. Cette diversité rend l’évaluation par technologies déclarées peu fiable et renforce l’intérêt d’une méthode centrée sur les décisions.
Contexte
En ESN, l’évaluation insiste davantage sur la capacité à entrer dans plusieurs patrimoines hérités, composer avec des standards différents, distinguer ce qui relève du contrat et ce qui relève de la responsabilité technique, et transférer une architecture exploitable au client. Le candidat doit savoir décider dans une relation où les équipes qui conçoivent, financent, exploitent et utilisent ne sont pas toujours les mêmes.
Niveau 1
Junior
Il comprend une architecture sur un périmètre borné et applique correctement les standards existants. Il identifie les composants principaux et leurs dépendances immédiates, mais raisonne encore souvent par produit ou par domaine technique. Il distingue difficilement une contrainte structurante d’une préférence d’exploitation.
Cliquer pour lire
Niveau 2
Confirmé
Il conçoit un sous-ensemble cohérent : socle de systèmes, architecture d’identité, service de stockage, segment réseau ou plateforme de virtualisation. Il compare plusieurs options, explicite ses hypothèses et traite les contraintes de sécurité, de capacité et de disponibilité. Sa limite fréquente est de produire une cible juste sans traiter suffisamment la migration ou la cohabitation avec l’existant.
Cliquer pour lire
Niveau 3
Sénior
Il relie systématiquement la cible à une trajectoire réalisable. Il arbitre entre standardisation et continuité, sécurité et activité, modernisation et dette de transition. Il identifie les dépendances entre systèmes, réseau, identité, stockage, sauvegarde et exploitation. Il prévoit les périodes de double fonctionnement, les fenêtres d’intervention et les retours arrière.
Cliquer pour lire
Niveau 4
Expert
Il tranche un compromis structurant en assumant son coût. Il peut décider de maintenir temporairement un système imparfait, de financer une double exploitation, d’accepter une hétérogénéité bornée ou de ralentir une migration afin de protéger la continuité du service. Il nomme explicitement ce que l’organisation accepte de perdre : simplicité, rapidité, homogénéité, budget ou confort d’exploitation.
Cliquer pour lire
Une infrastructure ne tient que si ses fondations sont cohérentes. Elle couvre la structuration des environnements Windows et Linux, les identités et accès, le réseau, le DNS et la virtualisation. Une faiblesse à ce niveau produit des dépendances invisibles.
Une architecture d’infrastructure est jugée lorsqu’un composant tombe, lorsqu’une donnée doit être restaurée ou lorsqu’un site devient indisponible. Une sauvegarde jamais restaurée n’est pas une garantie d’architecture.
Le patrimoine d’infrastructure ne se remplace presque jamais en une seule opération. Cette catégorie mesure la stratégie de migration, le séquencement et la cohabitation ancien-nouveau.
Les droits à privilèges, le cloisonnement, le durcissement et la journalisation doivent être intégrés dès la conception. Un socle sécurisé mais incompréhensible en production reste dangereux.
L’Architecte technique infrastructure décide rarement seul de l’ensemble du périmètre. Une architecture non adoptée n’existe que dans les documents.
La méthode en action
La scorecard en un regard — survoler un axe
Architecture et intégration