Bienvenue dans l’équipe. Voici ton onboarding. Puisse le sort vous être favorable.

Introduction

Jade vient de rejoindre votre équipe Platform.
Elle est brillante, motivée, un peu impressionnée par la stack.
Elle a été volontaire comme tribut pour travailler sur l’environnement de dev interne.
Elle espère apprendre, contribuer, et surtout… ne pas mourir dans les trois premiers jours.

Imaginons deux scénarii :

Timeline 1

Elle ouvre le Confluence.
87 pages. Certaines sont à jour.
D’autres semblent avoir été écrites pendant la première rébellion.

Elle clone un dépôt Git. Le README contient des instructions obsolètes, des commentaires douteux et une étape 'TODO' oubliée depuis 2021.

Elle installe ce qu’on lui dit… sauf que le script plante.
Une variable d’environnement oubliée, une version de Python non compatible, et un outil à installer manuellement.
Bienvenue dans l’arène.

Elle demande de l’aide.
Quelqu’un lui répond vaguement : “Tu dois suivre les étapes dans l’ordre.”
Mais l’ordre n’existe nulle part.

Le pipeline CI échoue sans message utile.
Vault ne lui donne pas accès aux secrets.
Elle n’a pas de visibilité sur ce qu’elle a fait correctement.
Et personne ne semble surveiller les tributs.

Au bout de trois semaines, Jade a à peu près tout installé.
Mais elle ne sait toujours pas si elle a bien fait.
Ni ce qu’elle est censée faire ensuite.

Elle ne s’est pas fait éliminer.
Mais elle survit à peine.
Elle est désengagée. Inerte. En mode ‘je vais attendre qu’on me dise quoi faire’.
Ou pire : “je vais faire comme avant”.

Timeline 2

Elle reçoit un message d’accueil :
“Bienvenue dans l’équipe Platform. Voici ton parcours d’onboarding.”

Elle clique.
Un petit dashboard s’ouvre, propre et accueillant.
Pas de piège, pas de distraction.

• Étape 1 : Créer un namespace personnel
• Étape 2 : Lancer un pipeline de test
• Étape 3 : Observer le déploiement dans le dashboard de l’équipe (Grafana)
• Étape 4 : Confirmer que tout est vert → validé

Chaque étape est guidée, contextualisée.
Les erreurs sont prévues. Les retours sont clairs.
Et surtout : elle comprend ce qu’elle est en train de faire.

Jade déploie une app de test en 2 jours.
Le lendemain, elle pose des questions pertinentes.
Le surlendemain, elle envoie une PR pour améliorer l’expérience.

Elle ne court plus pour sa survie.
Elle construit. Elle contribue.
Elle devient un atout.

Que s’est-il passé?

Même Jade.
Même équipe.
Même plateforme.

Mais deux expériences radicalement différentes.

Et ce qui a tout changé…
Ce n’est pas sa motivation.
Ce n’est pas sa compétence.
Ce n’est même pas la stack.

Ce qui a tout changé, c’est l’onboarding.
C’est la différence entre être larguée dans l’arène sans arc,
et démarrer avec un mentor, un plan, et une vraie chance de s’en sortir.

Bienvenue dans l’équipe. Voici ton onboarding.
Puisse le sort vous être favorable.

Pourquoi l’onboarding est stratégique ?

Dans les districts, l’arène est construite avec soin.
Chaque piège, chaque ressource, chaque rebord de falaise est placé avec une intention.
Pourquoi ? Parce que le spectacle doit être maîtrisé.

Dans une équipe, votre onboarding, c’est l’arène.
C’est la première rencontre entre vos utilisateurs et votre stack.
Et si c’est un chaos total, ne vous étonnez pas si personne ne veut y revenir.

Trop souvent, l’onboarding est vu comme un détail.
Une doc. Une checklist. Un rite de passage.

Mais en réalité, c’est un composant stratégique de votre architecture humaine.
C’est là que se joue :

• L’adoption de vos outils
• La montée en autonomie
• La confiance envers l’équipe

Un onboarding négligé, c’est comme une arène générée aléatoirement :
sans règles claires, sans terrain stable, sans issue visible.
Et les tributs… euh, les devs, passent plus de temps à survivre qu’à construire.

Parce que oui :
l’onboarding, ce n’est pas la cerise sur le gâteau de la DevEx.
C’est la porte d’entrée de toute votre stratégie.

Les erreurs classiques à éviter

Ce ne sont pas les pièges les plus mortels qui tuent en premier.
Ce sont les erreurs bêtes. L’eau contaminée. Les baies toxiques.
Et surtout : l’absence d’information!

Dans votre arène-platforme, c’est pareil.
Voici les pièges les plus courants qui tuent vos onboardings… à petit feu.

L’installation-puzzle

Un script à lancer… mais seulement après avoir exporté trois variables.
Un outil en version 2.4.1, mais surtout pas la 2.5.
Et bien sûr : un token généré manuellement via un outil que personne n’explique.

Résultat ?
Jade passe ses premiers jours à empiler des artefacts comme des branches humides.
Rien ne s’allume. Tout fume.

La doc-tombeau

Le wiki date de l’ère du feu.
Il a été écrit pour un autre cluster, un autre outil, un autre monde.

Il y a bien une doc, oui.
Mais elle ressemble à une carte falsifiée par le Capitole : elle vous envoie dans le mur avec un grand sourire.

Le mentor tribal

“Ah pour ça faut demander à Haymitch. C’est lui qui sait.”
Haymitch a tout en tête. C’est un survivant.
Mais il est en vacances. Et les sponsors n’ont laissé aucun coup de pouce!

L’information est là.
Mais elle est transmise par tradition orale.
Autant dire : inutile pour les nouveaux arrivants.

Le flou fonctionnel

Jade a tout installé.
Mais maintenant ? Elle est censée faire quoi ?
Déployer une app ? Intégrer un service ? Pousser une PR ?

Elle attend… un signal. Une mission. Une validation.
Mais il n’y a rien.
Juste le vide.

Le pipeline silencieux

Premier commit. Premier push.
Et là… le pipeline échoue.
Mais sans message.
Sans logs.
Sans indices.

Ce n’est plus un onboarding.
C’est une enquête judiciaire. Et Jade n’a pas le badge des Peacekeepers.

Et donc?

Ce ne sont pas des problèmes de documentation.
Ce sont des signaux faibles que votre plateforme n’est pas habitable.
Ou pire : qu’elle a été conçue sans penser aux humains.

Trois patterns qui sauvent la mise

Certains tributs ne survivent pas simplement parce qu’ils sont forts.
Ils survivent parce qu’ils ont compris les règles invisibles de l’arène.
Parce qu’ils observent.
Parce qu’ils utilisent les mécaniques du jeu… à leur avantage.

Progressive Disclosure

Ne balancez pas toute la stack dès le jour 1.
Ne donnez pas 19 outils, 42 paramètres, 12 templates et un cluster de test dès la première heure.

Commencez petit.
Un pipeline de démo.
Un namespace perso.
Un secret à injecter.
Un dashboard à observer.

Puis, plus tard, vous révélez :

Le vrai flux GitOps

Les stratégies de déploiement

Les conventions d’équipe

C’est l’équivalent de découvrir l’arène morceau par morceau,
au lieu de tomber dans un labyrinthe de pièges dès la première case.

Petit à petit, Jade découvre.
Elle n’est pas submergée.
Elle est guidée.

FTUE — First Time User Experience

On ne le dit pas assez, mais la première fois compte.
C’est là que se forment les jugements, les émotions, les liens.

Si ton onboarding commence par un 'ça marche pas',
tu as perdu du capital confiance. Peut-être pour toujours.

Une bonne FTUE (First-Time User Experience), c’est :

Un chemin clair
Des étapes qui valident quelque chose
Une victoire rapide (pour le shot de dopamine)

En gros, ce n’est pas un wiki.
C’est une expérience.
Conçue comme une feature produit.

Et souvenez-vous :
la première victoire doit arriver vite.
Sinon, c’est la galère qui s’installe.

Dans la timeline B, Jade voit son premier déploiement réussir.
Elle voit les logs.
Elle comprend le ‘pourquoi’ derrière le ‘comment’.
Et elle sent qu’elle peut gagner ce jeu.

La boucle de feedback

Une arène qui ne change jamais est une arène morte.
Elle favorise toujours les mêmes.
Elle devient prévisible, inefficace, injuste.

Votre onboarding doit évoluer.
Et pour ça, il a besoin d’une boucle de feedback.

Posez-vous cette question :
Quand avez-vous mis à jour votre onboarding pour la dernière fois ?
Et comment savez-vous qu’il est toujours utile ?

Créez une vraie boucle:

Un formulaire rapide en fin de parcours

Un tableau de complétion d’étapes (et là où ça coince)

Vous traquez les erreurs dans vos pipelines ?
Traquez aussi les douleurs dans le parcours utilisateur.

Parce qu’un onboarding sans feedback,
c’est comme une arène sans caméras.
Vous ne voyez rien. Vous n’apprenez rien.
Et vous condamnez les prochains à répéter les mêmes erreurs.

Améliorer son onboarding

On n’a pas besoin d’une refonte complète de l’onboarding.
On a juste besoin d’accepter que l’onboarding est une vraie feature produit.
Avec un design.
Avec des tests.
Avec des retours utilisateurs.

Et comme toutes les features de la plateforme, on peut l’améliorer avec une stratégie bien connue.

Que faire quand on réalise que son onboarding est… disons, un peu toxique ?
Quand on se rend compte que Jade vit en boucle la timeline maudite ?

Auditer comme un Game Maker

“Si vous ne pouvez pas le mesurer, vous ne pouvez pas l'améliorer.” (Lord Kelvin)

Commencez par observer l’arène.
Pas votre stack. Pas vos outils.
L’expérience du nouvel arrivant.

Posez-vous ces questions :

• Combien de temps entre “je commence” et” je déploie quelque chose d’utile” ?
• Combien d’étapes sont implicites, tribales, non documentées ?
• Combien d’outils sont nécessaires pour franchir le premier mur ?
• Combien de personnes faut-il déranger pour s’en sortir ?

Faites le test vous-même. Ou mieux : regardez un nouveau faire.
Sans l’aider.

S’il se retrouve à creuser un tunnel avec une cuillère rouillée… c’est que votre arène a un problème.

Versionner l’onboarding

On ne veut pas juste un document.
On veut un parcours.

Concrètement, ça peut être :

• Un dépôt Git avec un guide pas-à-pas
• Un dashboard interactif d’onboarding (même tout simple en React ou Markdown)
• Une PR de démarrage comme première mission

Le but, c’est que le parcours ne vive pas dans Confluence ou dans la tête de Haymitch.
Il doit être observable, versionné, et testable.

Comme n’importe quel composant de votre plateforme.

Instrumenter le parcours

“Vous devez voir ce qu’il se passe. Pas deviner.” (N’importe quel SRE) 
Posez des balises dans votre arène :

• Un taux de complétion
• Des étapes validées
• Des retours qualitatifs

Si Jade abandonne au niveau 2, vous devez le savoir.
Pas dans 6 mois. Immédiatement! (Ca peut être le rôle du mentor)

Conclusion

Jade n’a pas besoin qu’on la forme pendant trois mois.
Elle n’a pas besoin d’un ‘tech buddy’ qui lui explique tout à la main.

Elle a juste besoin qu’on ne la sacrifie pas dès le premier jour.
Qu’on ne la jette pas dans l’arène avec un ‘tiens, lis ça, bonne chance’

Une plateforme brillante techniquement mais incompréhensible,
c’est comme une arène truffée de pièges avec un panneau Bienvenue à l’entrée.

Vous pouvez avoir :

• Les meilleurs outils
• Les meilleures intentions
• La meilleure équipe

Mais si personne ne comprend comment rentrer dans votre système…
Alors votre système meurt. Lentement. En silence.
Et vous finirez à maintenir un truc que plus personne n’utilise.
Un cimetière de bonnes idées.

Vous êtes des Platform Engineers.
Pas des concepteurs de pièges.

Votre job, ce n’est pas de tester la résilience mentale des nouveaux.
C’est de leur construire un chemin.
Solide. Clair. Progressif.

Bienvenue dans l’équipe.
Voici ton onboarding.
Et puisse le sort… ne pas être la seule chose favorable.