9 entretiens d’architecture ratés avant de comprendre — les 7 étapes qui m’ont fait décrocher un poste senior | D-Open

TL;DR

• Sur 14 entretiens d’architecture passés en huit mois, j’en ai raté 9. Pas par manque de connaissances : par manque de méthode.
• L’erreur qui revient dans les 9 : dessiner avant d’avoir chiffré. Une architecture proposée sans ordre de grandeur ne peut pas être défendue.
• Ce qui est évalué n’est pas la solution finale, c’est la façon dont vous passez d’un énoncé flou à une décision argumentée.
• Les 7 étapes : cadrer → chiffrer → schéma minimal → nommer les arbitrages → dimensionner le goulot → anticiper les pannes → conclure sur les compromis.

Je me souviens très précisément du moment où j’ai compris. Sixième entretien, un éditeur lyonnais, on me demande de concevoir un système de notifications. Je dessine en trois minutes un schéma propre : file d’attente, travailleurs, base de données, cache. L’examinateur me regarde et me pose une seule question : « combien de notifications par seconde ? ».

Je n’en savais rien. Je n’avais pas demandé. J’avais produit une architecture qui aurait aussi bien convenu à mille notifications par jour qu’à cent mille par seconde — ce qui revient à dire qu’elle ne convenait à rien. Une architecture qui ne dépend d’aucun chiffre n’est pas une architecture, c’est un dessin.

Voici la méthode que j’ai construite après ces échecs, et qui m’a fait obtenir trois propositions sur les cinq entretiens suivants. Elle tient en sept étapes et un découpage du temps.

Le découpage du temps sur un exercice de 45 minutes

Étape 1 — Cadrer la demande avant de dessiner

Les cinq premières minutes ne servent pas à produire : elles servent à réduire l’incertitude. Un énoncé d’entretien est volontairement sous-spécifié, et le sous-spécifié est un test.

Posez systématiquement ces questions, dans cet ordre :

Qui utilise le système, et pour quoi ? Un système consulté par des humains et un système appelé par des machines n’ont pas les mêmes exigences de latence ni les mêmes pics.
Quelles opérations doivent absolument fonctionner ? Faites énoncer deux ou trois fonctions essentielles, et écrivez-les. Elles serviront de juge de paix.
Qu’est-ce qui est explicitement hors périmètre ? C’est la question que presque personne ne pose, et c’est celle qui vous fait gagner le plus de temps.
Quelle fraîcheur des données est acceptable ? Une seconde, une minute, une heure : la réponse détermine à elle seule la moitié de l’architecture.

Notez les réponses visiblement, dans un coin du tableau. Vous y reviendrez, et cela montre que vous concevez à partir de contraintes plutôt qu’à partir d’habitudes.

Étape 2 — Chiffrer la charge à voix haute

C’est l’étape que j’avais sautée pendant neuf entretiens. Elle prend cinq minutes et elle change tout, parce qu’elle transforme une discussion d’opinions en discussion de contraintes.

La méthode est un calcul de coin de table, assumé comme tel. Partez du nombre d’utilisateurs, dérivez les actions par utilisateur et par jour, ramenez à la seconde, puis appliquez un facteur de pointe. Énoncez chaque hypothèse à voix haute : votre examinateur corrigera les chiffres qui l’intéressent, et cette correction est une information précieuse.

Trois grandeurs suffisent :

Les requêtes par seconde, en régime moyen et en pointe. Un facteur de pointe de 3 à 10 est courant selon le métier.
Le volume stocké, en multipliant la taille moyenne d’un objet par le nombre d’objets créés par an.
Le rapport lectures / écritures, qui détermine où placer les caches et s’il faut des réplicas de lecture.

Un exemple de raisonnement complet : 200 000 utilisateurs actifs par jour, cinq actions chacun, soit un million d’actions réparties sur une journée — environ 12 par seconde en moyenne, disons 60 en pointe. À cette échelle, une base relationnelle unique et bien indexée suffit, et proposer une architecture distribuée serait un signal négatif. Le chiffre vous a évité une faute.

L’erreur qui coûte le plus cher

Sur-concevoir est plus pénalisant que sous-concevoir. Un candidat qui propose une file d’attente distribuée, un partitionnement et une réplication multi-région pour un service qui traite 60 requêtes en pointe démontre qu’il ne sait pas relier une décision à un besoin. Un candidat qui propose une base unique en assumant sa limite — « ceci tient jusqu’à environ 2 000 requêtes par seconde, au-delà je partitionne sur cette clé » — démontre exactement l’inverse. La séniorité, dans cet exercice, se lit à la capacité de ne pas faire.

Étape 3 — Poser un schéma minimal qui fonctionne

Dessinez maintenant, et dessinez la version la plus simple qui répond aux fonctions essentielles notées à l’étape 1. Client, point d’entrée, service, stockage. Rien d’autre.

Cette version simple joue deux rôles. Elle prouve que vous savez ce qui est strictement nécessaire, et elle vous donne une base sur laquelle ajouter des éléments en les justifiant. Chaque brique ajoutée ensuite répondra à un problème précis que vous aurez nommé — jamais à une habitude.

Annoncez-le explicitement : « je commence par la version la plus simple, puis je la fais évoluer là où elle casse ». Vous venez de donner à votre examinateur le plan de la suite de l’entretien, et vous reprenez la main sur le rythme.

Vous préparez un poste senior ou une mission longue ?

Nous mettons en relation des développeurs expérimentés avec des équipes qui recrutent sur des critères techniques réels, et nous préparons l’entretien d’architecture avec vous en amont.

Lance-toi

Étape 4 — Nommer les arbitrages explicitement

C’est ici que se joue la différence entre un profil confirmé et un profil senior. Un confirmé propose une solution ; un senior propose une solution et énonce ce qu’elle coûte.

La formulation qui fonctionne tient en une phrase type : « je choisis X plutôt que Y, parce que dans ce contexte Z compte plus que W ; le prix à payer est A, et je l’accepte parce que B ». Appliquée à un cache : je place un cache devant la base parce que le rapport lectures/écritures est de 20 pour 1 ; le prix est une fenêtre d’incohérence de quelques secondes, acceptable puisque l’étape 1 a établi qu’une fraîcheur à la minute suffisait.

Gardez en tête les arbitrages classiques et leurs coûts respectifs :

Décision	Ce qu’elle achète	Ce qu’elle coûte
Cache en lecture	Latence, décharge de la base	Fenêtre d’incohérence, invalidation à gérer
Traitement asynchrone	Réponse immédiate, absorption des pics	Complexité, suivi de l’état, cas de rejeu
Partitionnement	Passage à l’échelle en écriture	Requêtes transverses coûteuses, rééquilibrage
Réplicas de lecture	Débit en lecture	Retard de réplication, lectures obsolètes
Découpage en services	Autonomie des équipes	Latence réseau, cohérence distribuée, exploitation

Étape 5 — Dimensionner le goulot d’étranglement

Tout système a un composant qui cède en premier. Le nommer avant qu’on vous le demande est l’un des signaux de séniorité les plus forts de l’exercice.

Reprenez vos chiffres de l’étape 2 et demandez-vous : à quel endroit la charge dépasse-t-elle d’abord ce qu’un composant encaisse ? Le plus souvent, c’est l’écriture en base, la bande passante vers un service tiers, ou un traitement synchrone qui bloque un fil d’exécution.

Puis montrez comment vous le faites tenir : file d’attente en amont pour lisser, partitionnement sur une clé que vous justifiez, ou déport du traitement lourd hors du chemin critique. Un point souvent oublié : dites aussi à partir de quel seuil votre solution ne suffit plus. Cela prouve que vous connaissez ses limites.

Étape 6 — Anticiper les pannes et la reprise

Cinq à dix minutes doivent être consacrées à ce qui se passe quand ça casse. Beaucoup de candidats n’y arrivent jamais parce qu’ils ont passé trente minutes à dessiner.

Traitez trois scénarios, brièvement :

Un composant tombe. Que voit l’utilisateur ? Y a-t-il un mode dégradé, et lequel ? Une réponse en cache légèrement obsolète vaut mieux qu’une erreur.
Un traitement est rejoué. Vos opérations sont-elles idempotentes ? Si un message est livré deux fois, le client est-il débité deux fois ?
La charge double sans prévenir. Où se trouve la limitation de débit, et qu’abandonnez-vous en priorité ?

Sur la partie sécurité et cloisonnement, mentionner brièvement la gestion des secrets et le moindre privilège est bien vu — les équipes de WebGuard Agency rappellent que ces éléments se décident au moment de la conception, pas après la mise en production.

Étape 7 — Conclure en résumant les compromis

Gardez impérativement les trois dernières minutes. Un entretien qui s’arrête parce que le temps est écoulé laisse une impression d’inachevé ; un entretien que vous concluez laisse une impression de maîtrise.

Trois phrases suffisent : ce que vous avez choisi et pourquoi, ce que vous avez délibérément écarté, et ce que vous feriez avec une semaine de plus. Cette dernière partie est celle qu’on retient, parce qu’elle montre que vous savez distinguer une décision définitive d’un compromis d’exercice.

Un exemple : « j’ai choisi une base unique avec un cache en lecture, parce qu’à 60 requêtes en pointe le partitionnement serait prématuré. J’ai écarté le découpage en services, qui aurait ajouté de l’exploitation sans bénéfice à cette échelle. Avec plus de temps, j’instrumenterais d’abord le rapport lectures/écritures réel avant de figer la stratégie de cache. »

Ce qui a réellement changé entre l’entretien 9 et l’entretien 10

Rien sur le plan des connaissances. Je ne connaissais pas une brique de plus, je n’avais pas révisé un algorithme supplémentaire. Ce qui a changé tient en deux gestes : j’ai commencé à poser des questions avant de dessiner, et j’ai commencé à énoncer le prix de chaque choix.

Avec le recul, l’exercice n’évalue pas votre capacité à concevoir un système — personne ne conçoit sérieusement un système en 45 minutes au tableau. Il évalue votre comportement face à un problème mal défini, ce qui est exactement le quotidien d’un poste senior. Les examinateurs cherchent quelqu’un avec qui il sera possible de réfléchir, pas quelqu’un qui a la bonne réponse.

Si vous êtes en train de structurer votre recherche plus largement, notre guide comment créer un portfolio de développeur couvre le volet dossier et démonstration technique, qui joue souvent avant même l’entretien d’architecture.

Résultats sur 14 entretiens — avant et après la méthode

Questions fréquentes

Faut-il apprendre par cœur des architectures types ?

Connaître quelques architectures de référence aide à ne pas partir de zéro, mais les réciter est le meilleur moyen d’échouer. Un examinateur expérimenté repère immédiatement la solution plaquée : elle arrive trop vite, elle ne s’appuie sur aucun chiffre issu de l’énoncé, et elle ne bouge plus quand on change une contrainte. Ce qui est évalué n’est pas votre catalogue de schémas, c’est votre capacité à passer d’un besoin flou à une décision argumentée. Apprenez les briques et leurs coûts respectifs — file d’attente, cache, réplication, partitionnement — plutôt que des assemblages tout faits.

Combien de temps faut-il consacrer à la préparation ?

Trois semaines à raison de quelques heures par semaine suffisent à un développeur qui a déjà une expérience réelle de la production. La première semaine sert à réviser les ordres de grandeur et les coûts des briques classiques. La deuxième à s’entraîner à voix haute sur cinq ou six énoncés, en respectant strictement le découpage du temps. La troisième à faire deux simulations avec quelqu’un qui vous interrompt et change les contraintes en cours de route. Au-delà d’un mois, le rendement décroît nettement : ce qui manque à ce stade relève de l’expérience de production, pas de la révision.

Que faire quand on ne connaît pas le domaine proposé ?

C’est la situation la plus fréquente, et elle est prévue. Personne n’attend d’un candidat qu’il connaisse le métier de la billetterie, de la logistique frigorifique ou du paiement fractionné. Dites-le franchement, puis posez les questions qui vous permettent de reconstruire le modèle : qui écrit, qui lit, à quelle fréquence, quelle fraîcheur est acceptable, que se passe-t-il si une opération est perdue. Un candidat qui reconstitue un domaine inconnu en cinq questions démontre exactement la compétence recherchée. Un candidat qui fait semblant de connaître se fait démasquer au premier chiffre.

L’exercice est-il le même en France et dans les entreprises américaines ?

Le format est proche, l’attente diffère sur un point. Les processus calqués sur les grandes entreprises américaines valorisent souvent le passage à très grande échelle, avec des ordres de grandeur volontairement extrêmes. Dans la majorité des entreprises françaises — éditeurs, ETI, ESN, scale-ups — l’examinateur cherche plutôt à voir si vous savez ne pas sur-concevoir : proposer une architecture distribuée complexe pour un service qui traite quelques centaines de requêtes par seconde est un signal négatif. Adaptez l’ambition à l’échelle réelle de l’entreprise en face, et dites explicitement pourquoi vous n’allez pas plus loin.

En résumé

L’entretien d’architecture n’est pas un examen de connaissances, c’est une mise en situation. On vous donne un problème volontairement flou pour observer comment vous le rendez net. Les candidats qui échouent sont rarement ceux qui savent le moins ; ce sont ceux qui dessinent avant d’avoir demandé, et qui présentent des choix comme des évidences.

Les sept étapes tiennent en une phrase à retenir : cadrez, chiffrez, commencez simple, énoncez le prix de chaque décision, nommez ce qui cède en premier, prévoyez la panne, et concluez vous-même. Entraînez-vous à voix haute sur cinq énoncés en respectant le découpage du temps, et vous aurez fait l’essentiel du chemin.

Prêt à passer sur des postes et des missions à la hauteur ?

Nous travaillons avec des équipes françaises qui évaluent sur des critères techniques réels. Envoyez-nous votre profil : nous vous préparons à l’entretien d’architecture avant de vous présenter.