J’ai raté 6 recrutements d’architecte cloud AWS senior — les 7 étapes de l’exercice qui trie enfin

William

Expert sourcing de talents · 6 septembre 2026 · 14 min de lecture

Six recrutements, six profils impeccables sur le papier, et le même constat au bout de quelques mois : la personne connaissait parfaitement la plateforme, mais n’arrivait pas à faire prendre une décision. Le problème n’était pas les candidats. C’était l’épreuve que nous leur faisions passer. Voici celle que nous utilisons depuis, et la méthode pour la construire.

Pourquoi les entretiens techniques classiques échouent sur ce poste

Un entretien d’architecte cloud ressemble souvent à un interrogatoire de catalogue. On demande la différence entre deux modes de réplication, à quoi sert tel service managé, comment fonctionne tel mécanisme de mise en cache. Les bonnes réponses arrivent, on coche, on avance.

Le problème est que ces questions mesurent une chose que le poste ne demande presque jamais. Un architecte senior ne passe pas ses journées à réciter des différences de services : il passe ses journées à trancher entre des options toutes imparfaites, devant des équipes qui ne sont pas d’accord, avec un budget déjà engagé et un existant qu’il n’a pas choisi.

Cette compétence-là est invisible dans un questionnaire. Elle devient visible dès qu’on met la personne devant un système réel, avec des contraintes réelles, et qu’on observe comment elle s’y prend plutôt que ce qu’elle sait.

C’est la différence entre un examen et une mise en situation. Les six recrutements que nous avons ratés avaient tous parfaitement réussi l’examen.

Étape 1 — Écrire la grille de notation avant de choisir l’exercice

L’ordre compte, et il est contre-intuitif. La tentation est de préparer un beau cas puis d’improviser l’évaluation. Résultat : la grille finit par décrire le dernier candidat rencontré, et l’équipe recrute par comparaison au lieu de recruter par critère.

Commencez par écrire, en une page, ce que vous voulez observer. Pas des qualités abstraites — « esprit d’analyse », « leadership technique » — mais des comportements observables pendant l’exercice. Par exemple :

• a demandé quel est le budget, ou l’a explicitement noté comme information manquante ;
• a identifié au moins un point de défaillance unique dans le schéma présenté ;
• a distingué ce qui doit être décidé maintenant de ce qui peut attendre ;
• a nommé au moins un compromis qu’il accepte, avec sa conséquence.

Quatre à six critères suffisent. Au-delà, personne ne les remplit pendant l’entretien, et la grille devient un document de conformité qu’on complète après coup — c’est-à-dire de mémoire, c’est-à-dire biaisé.

Étape 2 — Partir d’un schéma réel et imparfait, jamais d’un cas d’école

Le support de l’exercice doit être un de vos systèmes, anonymisé si nécessaire, avec ses défauts. Pas un cas d’école propre, pas une architecture de référence tirée d’un guide.

La raison est directe : un cas d’école a une bonne réponse, et l’exercice se transforme en jeu de devinette. Un système réel n’a pas de bonne réponse, il a des compromis, et c’est là que les seniors se distinguent des autres.

Le schéma doit contenir, idéalement sans le signaler, au moins trois choses : une décision historique discutable que quelqu’un a prise pour de bonnes raisons il y a trois ans, un point de défaillance unique que personne n’a traité, et une zone floue où le schéma lui-même est incomplet.

Ce troisième élément est le plus utile de tous. Un candidat moyen construit sa réponse sur la zone floue en supposant ce qui l’arrange. Un senior s’arrête et demande : « qu’est-ce qu’il y a exactement à cet endroit ? ». La différence apparaît en quatre minutes.

Étape 3 — Imposer trois contraintes non négociables

Sans contrainte, tout le monde propose la même architecture idéale, et l’exercice ne discrimine rien. Les contraintes sont ce qui transforme un exposé en décision.

Trois suffisent, et elles doivent être chiffrées et incompatibles entre elles :

• Un budget, exprimé en coût mensuel d’exploitation ou en jours-hommes disponibles. C’est la contrainte que les candidats oublient le plus souvent de demander.
• Un délai, avec une date et un événement métier derrière — une saison commerciale, une échéance réglementaire. Un délai sans motif n’est pas crédible et se négocie ; un délai motivé se subit.
• Un élément de l’existant intouchable, pour de bonnes ou de mauvaises raisons : une base de données que l’on ne migre pas, un fournisseur imposé, une équipe qui maintient un composant hérité.

La troisième contrainte est celle qui révèle le plus. Beaucoup de candidats brillants commencent par expliquer pourquoi il faudrait la supprimer. C’est une réponse légitime une fois ; c’est un signal d’alerte quand elle occupe vingt minutes, parce que le poste consiste précisément à composer avec ce qu’on ne peut pas changer.

Étape 4 — Mesurer les questions posées avant d’écouter les réponses

C’est le cœur de la méthode, et l’étape que nous avons mis le plus longtemps à comprendre.

Pendant les dix premières minutes, ne notez pas les propositions. Notez les questions. Combien, dans quel ordre, et sur quoi elles portent. Notre observation, sur une vingtaine d’entretiens depuis que nous procédons ainsi, est nette :

La dernière ligne mérite d’être soulignée. Une architecture reflète toujours l’organisation qui l’a produite ; un architecte qui l’ignore proposera des refontes que personne n’acceptera. Ceux qui posent la question du « pourquoi historique » sont ceux qui, plus tard, font effectivement bouger les choses.

Étape 5 — Introduire un changement en cours d’exercice

À mi-parcours, quand la personne a posé son raisonnement, changez une contrainte. Une seule, annoncée simplement : « le budget vient d’être divisé par deux », ou « la date avance de trois semaines », ou « le composant que vous vouliez garder est en fin de support dans six mois ».

Ce que vous observez ici n’est pas la nouvelle solution. C’est la vitesse et la nature de la réaction. Trois comportements ressortent :

• Défendre le plan initial. La personne explique pourquoi la nouvelle contrainte est déraisonnable. En entreprise, ce comportement produit des projets qui déraillent en silence.
• Recommencer de zéro. Signe d’un raisonnement peu structuré : si l’architecture était modulaire dans la tête de son auteur, un changement de contrainte n’en invalide qu’une partie.
• Identifier ce qui tient et ce qui tombe. « Les deux premières briques restent, la troisième devient impossible, voilà ce que je propose à la place et ce que ça coûte. » C’est la réponse d’un senior, et elle arrive en moins de deux minutes.

Cette étape est aussi celle qui vous protège du candidat très préparé. On peut réviser des architectures de référence ; on ne peut pas réviser sa manière de réagir à un imprévu.

Étape 6 — Demander ce que la personne renonce à faire

Posez la question littéralement, à la fin : « qu’est-ce que votre proposition ne fait pas ? »

C’est la question la plus discriminante de tout l’exercice, et la plus simple à évaluer. Un architecte senior répond en trente secondes, avec deux ou trois renoncements assumés et leur conséquence : « on n’aura pas de bascule automatique entre régions, donc en cas d’incident majeur on repart en deux heures, pas en cinq minutes — et c’est acceptable au vu du budget ».

Un profil moins mûr répond que sa proposition couvre tout, ou énumère des améliorations futures au lieu de renoncements présents. La différence n’est pas une question de connaissance : c’est une question de rapport à la contrainte.

Nous avons ajouté cette question après le quatrième échec. Elle explique à elle seule une bonne partie de nos décisions depuis, et elle ne coûte rien.

Étape 7 — Noter séparément, puis confronter les notes

Deux évaluateurs minimum, chacun remplit la grille avant toute discussion. C’est une contrainte pénible et elle est non négociable.

La raison est le principal biais de ce format : l’aisance orale. Elle est corrélée à la confiance en soi, pas à la qualité des arbitrages, et elle contamine instantanément l’évaluation collective. Le premier avis exprimé dans une salle devient l’ancre de tous les suivants.

Quand les notes divergent — et elles divergent souvent — la discussion devient utile : l’un a été convaincu par la clarté de l’exposé, l’autre par la pertinence des questions posées. C’est exactement le débat qu’il faut avoir, et il n’a lieu que si les notes ont été écrites avant.

Notre règle finale : un désaccord persistant entre deux évaluateurs est un « non ». Sur un poste d’architecte, le coût d’un mauvais recrutement se paie sur trois ans de décisions techniques. Ce n’est pas le poste où l’on prend le bénéfice du doute.

Les trois erreurs que nous avons commises

Donner le schéma à l’avance. Nous l’avons fait deux fois, par politesse. Résultat : l’exercice mesurait le temps de préparation disponible, ce qui favorise les candidats sans contrainte personnelle et efface le signal le plus utile — la capacité à poser les bonnes questions à froid.

Prolonger l’exercice au-delà de quatre-vingt-dix minutes. Passé ce seuil, on ne mesure plus de la compétence mais de l’endurance, et on écarte mécaniquement d’excellents profils qui refusent, à juste titre, d’y consacrer une demi-journée.

Chercher un architecte qui connaît déjà notre stack. C’est le critère qui nous a coûté le plus cher. Un architecte compétent apprend une plateforme en quelques semaines ; personne n’apprend en quelques semaines à faire prendre une décision à trois équipes qui ne s’entendent pas. Le même raisonnement s’applique lorsqu’on structure un budget de recrutement : les critères qui pèsent réellement sont détaillés dans notre méthode d’estimation appliquée aux plateformes de recrutement en ligne.

Sur les sujets techniques que ces profils devront arbitrer, deux ressources complètent utilement l’exercice : les questions d’exploitation d’automatisations en production documentées par Plug-Tech, et le volet résilience et sécurité traité par WebGuard, dont les constats sur les points de défaillance uniques rejoignent exactement ce que l’exercice cherche à détecter.

Questions fréquentes