J’ai raté l’intégration de 2 architectes AWS senior — les 7 étapes des 30 premiers jours que j’applique depuis

William

Expert sourcing de talents · 5 septembre 2026 · 12 min de lecture

Nous avons perdu deux architectes cloud AWS senior en moins de six mois chacun. Aucun des deux n’était en cause : le recrutement était bon, les compétences étaient là. C’est l’intégration qui était ratée, et elle l’était de la même façon les deux fois. Voici le plan de trente jours que nous appliquons depuis, étape par étape, avec ce qu’il corrige.

Pourquoi ce poste rate plus souvent que les autres

Un développeur qu’on intègre mal produit moins vite. Un architecte qu’on intègre mal ne produit rien du tout, et c’est une différence de nature. Son travail consiste à prendre des décisions qui engagent l’infrastructure sur plusieurs années. Ces décisions supposent deux choses qu’on ne lui donne presque jamais : une vision complète de l’existant, et un mandat clair pour trancher.

Dans les deux échecs que nous avons vécus, le scénario était identique. La personne arrive, on lui donne un accès en lecture partiel « le temps de valider les habilitations », elle passe six semaines à reconstituer l’existant en interrogeant des collègues, elle produit enfin un diagnostic — et découvre que trois des cinq recommandations sortent de son périmètre de décision. Au quatrième mois, elle cherche ailleurs.

La bonne nouvelle, c’est que ces deux causes se traitent avant l’arrivée, avec du travail administratif ingrat et zéro budget.

Étape 1 — Préparer les accès avant le jour 1

La règle est simple : toutes les lectures au jour 1, les écritures progressivement. Concrètement, avant l’arrivée, il faut avoir provisionné l’accès en lecture à la console de tous les comptes, l’accès à la facturation détaillée par service et par étiquette, l’accès aux journaux et aux métriques, l’accès aux dépôts d’infrastructure as code, et l’accès aux outils de ticketing et de documentation.

La facturation détaillée est celle qu’on oublie systématiquement, et c’est la plus importante. Un architecte cloud qui ne voit pas ce que coûte chaque service travaille à l’aveugle sur la moitié des arbitrages qu’on attend de lui. Si votre processus interne interdit de donner cet accès rapidement, il faut le savoir avant de recruter, pas après.

Un test utile la veille de l’arrivée : connectez-vous avec les identifiants préparés et vérifiez que chaque accès fonctionne réellement. Un accès « créé » mais bloqué par une politique parente est un accès qui n’existe pas, et personne ne s’en aperçoit avant le premier jour.

Étape 2 — Écrire le périmètre de décision noir sur blanc

C’est l’étape que tout le monde saute et celle qui détermine tout le reste. Il faut produire un document d’une page, avant l’arrivée, qui répond à trois questions.

• Qu’est-ce que cette personne décide seule ? Choix de services, structure des comptes, conventions d’étiquetage, standards d’infrastructure as code.
• Qu’est-ce qu’elle propose et fait valider ? Engagements financiers pluriannuels, changements de fournisseur, tout ce qui touche à la conformité.
• Qu’est-ce qui ne relève pas d’elle du tout ? C’est la partie la plus utile, et la plus douloureuse à écrire honnêtement.

Ce document se relit à voix haute avec la personne pendant la première semaine. S’il diverge de ce qui a été promis en entretien, mieux vaut le découvrir à J+3 qu’à J+120. Une divergence identifiée tôt se négocie ; découverte tard, elle produit une démission.

Étape 3 — Livrer la dette technique documentée, pas la version optimiste

Chaque plateforme a ses zones sales : le compte historique que personne n’ose toucher, la base sur une version obsolète, le script de déploiement qu’une seule personne sait relancer, les ressources dont on ignore l’usage.

L’instinct est de présenter la version propre pendant les premières semaines. C’est une erreur coûteuse : la personne va découvrir ces zones de toute façon, et elle les découvrira au pire moment — pendant un incident, ou après avoir bâti un plan qui les ignore.

Préparez donc une liste écrite et assumée : ce qui est fragile, ce qui n’est pas documenté, ce qui dépend d’une seule personne, ce qu’on n’a jamais osé redémarrer. Cette liste rend deux services. Elle évite les mauvaises surprises, et elle envoie un signal de maturité qui compte énormément pour un profil senior : on peut parler des vrais problèmes ici.

Étape 4 — Organiser 8 entretiens avec ceux qui subissent la plateforme

Pendant la première quinzaine, planifiez huit entretiens d’une demi-heure. Pas avec le comité de direction : avec les gens qui utilisent l’infrastructure au quotidien. Deux développeurs qui déploient souvent, la personne d’astreinte, celle qui gère les sauvegardes, un responsable produit qui attend des environnements, la personne qui reçoit la facture, un profil sécurité, et le dernier arrivé dans l’équipe technique.

Ce dernier est le plus précieux et le moins convié. Quelqu’un arrivé il y a trois mois se souvient encore de tout ce qui l’a surpris, alors que les anciens ont normalisé les anomalies. C’est souvent lui qui décrit le mieux les frictions réelles.

Une seule question suffit à ouvrir chaque entretien : « qu’est-ce qui te fait perdre le plus de temps aujourd’hui ? ». Les réponses convergent vite, et elles convergent presque toujours vers des problèmes différents de ceux qu’on avait listés en réunion de direction.

Étape 5 — Exiger un état des lieux écrit à J+15

À la fin de la deuxième semaine, demandez un document de trois à cinq pages. Pas une présentation, un document écrit : le format oblige à préciser ce que les diapositives permettent de survoler.

Le plan attendu tient en quatre parties : ce qui fonctionne bien et doit être préservé, les trois risques les plus sérieux avec leur conséquence concrète, les trois gains les plus accessibles, et les questions restées sans réponse. Cette dernière partie est la plus révélatrice de toutes — elle montre où l’information est introuvable dans l’organisation.

Ce document a une deuxième vie, souvent sous-estimée. Il devient la référence partagée entre l’architecte et le reste de l’équipe, et il permet six mois plus tard de vérifier si les priorités annoncées ont été tenues. C’est la même logique de trace écrite que celle que nous appliquons à l’organisation d’une astreinte en petite équipe : ce qui n’est pas écrit se renégocie indéfiniment.

Étape 6 — Choisir un premier chantier livrable en deux semaines

Entre J+15 et J+30, la personne doit livrer quelque chose. Pas concevoir, pas cadrer : livrer. Le critère est triple — visible par d’autres équipes, terminable en deux semaines, et sans risque de casse majeure en cas d’échec.

Trois candidats qui fonctionnent presque partout : rendre la facture lisible par service et par équipe, ce qui est presque toujours possible et presque jamais fait ; supprimer les ressources orphelines identifiées pendant l’état des lieux, ce qui produit une économie chiffrable ; ou automatiser une opération manuelle récurrente que quelqu’un fait à la main toutes les semaines.

Le mauvais choix, systématiquement, est la grande migration structurante. Elle prend six mois, ne produit aucun signal intermédiaire, et laisse la personne sans crédibilité démontrable pendant tout ce temps. Un architecte senior qui n’a rien livré de visible au bout d’un mois commence à être perçu comme un coût, et cette perception est très difficile à inverser ensuite.

Étape 7 — Faire un point de calibrage à J+30 avec des critères écrits

Le point de trentième jour n’est utile que si ses critères ont été écrits avant l’arrivée. Sinon, il devient une conversation d’ambiance où chacun confirme ses impressions.

Trois signaux suffisent. L’état des lieux est reconnu comme juste par les autres équipes — pas approuvé, reconnu comme une description fidèle de la réalité. Le premier chantier est livré, ou l’obstacle qui l’a bloqué est identifié précisément. D’autres équipes sollicitent spontanément la personne sur leurs sujets, ce qui est le meilleur indicateur d’intégration réelle et le seul qu’on ne peut pas simuler.

Si les trois signaux sont là, la trajectoire est bonne. S’il en manque un, il faut regarder lequel et pourquoi. Si les trois manquent, l’expérience nous a appris que la cause est presque toujours organisationnelle : accès incomplets, mandat flou, ou chantier mal choisi. Conclure à un problème de compétence à J+30 est très rarement le bon diagnostic, et c’est celui qui coûte le plus cher — parce qu’il conduit à recommencer un recrutement au lieu de corriger un processus.

Ce qui se joue après le premier mois

Trente jours ne suffisent pas à juger un architecte, et ce n’est pas l’objectif. L’objectif est d’avoir supprimé tous les obstacles qui ne dépendent pas de la personne, pour que les mois suivants mesurent réellement son travail.

Au deuxième mois, le sujet devient la trajectoire : quelles décisions structurantes prendre, dans quel ordre, avec quel budget. C’est là que le périmètre écrit à l’étape 2 se révèle payant ou coûteux. Au troisième mois, le sujet devient la transmission : ce que la personne documente, ce qu’elle automatise, ce qu’elle apprend aux autres.

Cette logique d’intégration se transpose à d’autres profils techniques senior. Elle est très proche de celle que nous décrivons pour la sélection d’un architecte cloud AWS senior en amont, et elle s’applique aussi bien aux équipes qui construisent un CRM sur mesure qu’à celles qui montent une plateforme de mise en relation. Sur le volet coûts, les mêmes réflexes se retrouvent dans notre méthode de réduction de facture cloud.

Questions fréquentes