Architecte cloud

L’architecte cloud, ou cloud architect, conçoit une architecture technique adaptée aux besoins de l’entreprise. Il relie les objectifs métier aux choix de réseau, de calcul, de stockage et de sécurité. Son rôle est de rendre ces choix cohérents entre eux et avec le système d’information existant, puis d’accompagner leur mise en œuvre.

Son intervention porte sur une solution complète : les applications à intégrer, leurs échanges de données et les moyens nécessaires à leur fonctionnement. Il prend en compte les contraintes des métiers, les objectifs du système d’information et les conditions d’exploitation. La taille de l’organisation, sa complexité et son secteur font varier l’étendue de cette responsabilité.

Pour cadrer le poste, précisez son interlocuteur de décision dans la direction technique ou informatique. Définissez aussi les équipes avec lesquelles il travaillera : développement, exploitation, sécurité et données. Le titre seul ne dit pas quelle part de la réalisation lui sera confiée. Selon le poste, l’architecte participe directement à la mise en œuvre ou accompagne les équipes qui déploient la solution.

Architecte cloud, DevOps et sécurité : qui fait quoi ?

• Architecte cloud : lui confier la cohérence de la conception, les choix d’intégration et les règles techniques de la solution.
• DevOps : préciser avec l’équipe la répartition de l’automatisation et du déploiement. La fiche DevOps engineer aide à approfondir ce périmètre voisin.
• Sécurité : convenir des exigences de protection à intégrer et des validations à partager avec les spécialistes concernés.

Cette répartition est à adapter à votre organisation. Elle permet de formuler une attente précise : quelles décisions l’architecte doit-il préparer, lesquelles peut-il valider et jusqu’où doit-il intervenir dans leur réalisation ?

Les choix d’architecture engagent la robustesse, l’évolutivité, la sécurité, la performance et la maîtrise des coûts. Pour un dirigeant, l’enjeu est de relier chaque choix à un besoin réel : maintenir un service disponible, accompagner l’évolution des usages ou intégrer une application dans l’existant.

Un arbitrage utile explicite ses contraintes. Demandez ce que la solution doit supporter, quelles interruptions sont acceptables et quelles données elle doit protéger. Ces réponses donnent un cadre à la conception. Elles permettent aussi de discuter une option technique sans faire du fournisseur ou de l’outil le point de départ du projet.

Rendre les compromis compréhensibles

Lorsqu’une option est retenue, faites préciser les bénéfices attendus, les limites et les conséquences pour les équipes. Une architecture doit rester compréhensible par ceux qui la mettent en œuvre et l’exploitent. La documentation peut conserver les raisons du choix afin que les décisions suivantes tiennent compte de ce contexte.

La question des dépenses mérite le même niveau d’explication. Demandez sur quelles hypothèses repose le choix et quels usages pourraient le remettre en cause. Pour préciser la responsabilité consacrée aux coûts cloud, vous pouvez approfondir le périmètre du FinOps engineer.

Exemple fictif : une entreprise souhaite migrer une application dont plusieurs équipes dépendent chaque jour. Avant de choisir une cible, l’architecte examine les échanges avec les systèmes existants et les contraintes de continuité. La décision doit expliquer comment ces dépendances seront prises en compte pendant la migration.

• Analyser les besoins métier, les contraintes techniques et les composants du système existant.
• Évaluer les risques d’une migration et les dépendances entre applications, données et réseaux.
• Concevoir la cible cloud et définir les standards techniques associés.
• Choisir les services et les modalités d’intégration selon les exigences de sécurité, de performance et d’évolutivité.
• Formaliser les décisions dans les documents et schémas d’architecture du projet.
• Accompagner le déploiement et la migration avec les équipes techniques en tenant compte de la continuité des opérations.
• Analyser l’effet des nouvelles technologies et de l’évolution des besoins sur l’architecture.

Les parcours en architecture des systèmes d’information peuvent conduire au métier d’architecte cloud. Ils développent notamment la compréhension du système existant, l’analyse des besoins, la conception d’une cible et l’intégration des composants. Un intitulé de formation ne suffit pas à décrire les responsabilités que la personne peut prendre.

Quelle place donner aux certifications ?

Les certifications éditeurs attestent des compétences dans leur propre environnement. Elles apportent un repère sur les domaines abordés. Le référentiel Microsoft couvre notamment la conception de l’identité, du stockage, de la continuité et de l’infrastructure.

Les conditions d’obtention diffèrent : Microsoft exige Azure Administrator Associate pour son titre Azure Solutions Architect Expert, tandis que Google n’indique aucun prérequis à l’examen Professional Cloud Architect. Ces conditions concernent les certifications, pas une règle commune de recrutement.

Pour évaluer un architecte cloud, adaptez les étapes suivantes aux décisions et aux contraintes du poste à pourvoir.

1. Définir les critères avant les entretiens

Décrivez les décisions que la personne devra prendre : concevoir une cible, préparer une migration ou assurer la cohérence entre plusieurs systèmes. Précisez la part de mise en œuvre attendue.

Limitez la grille à une dizaine de critères prioritaires. Distinguez ceux qui se vérifient sur le parcours de ceux qui demandent une question ou un exercice, et associez une modalité d’évaluation à chacun.

Pour ce poste, vous pouvez retenir la compréhension des besoins, la cohérence technique, les compromis et la transmission aux équipes. Distinguez les connaissances indispensables à l’arrivée de celles qui peuvent être acquises.

Associez un interlocuteur métier à ce cadrage. Faites-lui formuler les contraintes de service dans ses propres termes, afin que l’évaluation technique reste liée à un besoin compréhensible.

2. Examiner une réalisation passée

Demandez au candidat de présenter une architecture sur laquelle il a réellement travaillé. Faites préciser le contexte, sa responsabilité personnelle et les décisions prises avec d’autres personnes.

Appuyez l’échange sur un schéma anonymisé ou une reconstitution. Demandez : « Quelles contraintes ont déterminé cette conception ? » Puis : « Quelle option avez-vous écartée, et pour quelle raison ? »

Un signal favorable est une explication qui relie les composants aux besoins et distingue les faits connus des hypothèses. Creusez une réponse centrée sur les noms d’outils ou qui laisse floue sa contribution.

3. Proposer un cas proche du poste

Exemple fictif : proposez la migration d’une application qui échange des données avec un système conservé dans l’entreprise. Fournissez les besoins connus et les contraintes de continuité.

Demandez au candidat de formuler ses questions avant de dessiner une cible. Faites-lui présenter les dépendances à examiner et les choix qu’il peut déjà argumenter.

Invitez-le à expliquer comment il aborderait le réseau, les accès, les données et la reprise. Introduisez ensuite une contrainte nouvelle et observez la manière dont il réexamine sa proposition.

Évaluez la qualité du raisonnement avec votre grille. Une proposition qui rend visibles ses limites est un signal utile. Une certitude maintenue sans traiter la nouvelle contrainte mérite d’être approfondie.

4. Tester la communication et la coopération

Demandez une restitution courte à un interlocuteur non spécialiste. Observez si le candidat explique les conséquences du choix et les décisions encore ouvertes sans perdre la précision nécessaire.

Explorez ensuite un désaccord vécu avec le développement, l’exploitation ou la sécurité. Demandez comment les arguments ont été discutés et comment la décision a été transmise.

Si le poste comprend de la coordination, examinez cette responsabilité séparément. Ne déduisez pas une aptitude à encadrer de la seule aisance technique.

5. Consolider l’appréciation

Comparez les observations de chaque évaluateur avec les critères initiaux. Notez ce qui a été démontré, ce qui reste incertain et ce qui demanderait un accompagnement à la prise de poste.

Avec l’accord du candidat, une référence professionnelle peut éclairer les points encore ouverts : replacez la compétence dans le contexte de la collaboration, puis demandez un exemple concret. Pour ce poste, l’échange peut porter sur le rôle exercé, la coopération et le suivi des décisions.

Si votre entreprise ne dispose pas de l’expertise technique nécessaire, associez un spécialiste capable de discuter la conception. Conservez en interne l’appréciation du besoin métier et du périmètre à confier.