Mes 4 premiers mois chez Indy

Il y a quatre mois, je prenais la direction de Lyon pour mon premier jour chez Indy.

Pendant les entretiens, on m’avait beaucoup parlé de la façon de travailler chez Indy, de l’autonomie, de la confiance et surtout de l’importance accordée à l’humain.

Sur le papier, tout ça sonnait très bien. Mais entre ce qu’on te raconte pendant un recrutement et ce que tu découvres réellement une fois arrivé, il peut parfois y avoir un écart.

De mon côté, j’avais surtout une question assez simple. Est-ce que je vais réussir à trouver ma place ?

Quatre mois plus tard, j’avais suffisamment de recul pour revenir sur ces premières semaines et voir comment cette question avait évolué.

Et pour raconter tout ça, autant repartir du début.

Lyon, lundi 2 mars 2026, 11h45.

Premier jour

J’arrive dans les bureaux et je suis tout de suite accueilli. Avec les autres membres de ma promo d’onboarding, on commence par faire le tour des locaux, découvrir les différents espaces et croiser quelques équipes.

La promo est assez variée. Je suis le seul développeur, entouré de personnes venant du SEO, du Growth ou encore de la gestion de projets stratégiques.

On passe cette première journée ensemble à découvrir Indy, avant que chacun rejoigne progressivement son équipe.

Petit détail, mon équipe n’est pas au bureau ce premier jour. Elle doit me rejoindre le lendemain.

Je me retrouve donc dans l’espace des développeurs sans vraiment connaître personne.

Je n’ai même pas le temps de me demander avec qui déjeuner, à peine mes affaires posées, le Team Lead d’une autre équipe vient me souhaiter la bienvenue. Il sait déjà qui je suis et que c’est mon premier jour, me présente aux autres et m’indique avec qui aller manger.

Ça peut sembler anodin, mais quand tu arrives quelque part sans connaître personne, ça change beaucoup de choses.

Un peu plus tard, entre midi et deux, j’entends quelqu’un jouer du piano dans les bureaux.

Je m’approche par curiosité et je commence à discuter avec un développeur d’une autre équipe.

À ce moment-là, c’est simplement une discussion autour d’un piano. Rien de très stratégique 😄.

Finalement, on reste un bon moment à discuter. Il me présente à d’autres personnes et on garde contact les semaines suivantes.

Je ne le savais pas encore, mais quelques semaines plus tard, j’allais justement devoir travailler avec lui sur un sujet qui dépassait le périmètre de mon équipe.

J’y reviendrai.

À la fin de cette première journée, je ne connais toujours pas la codebase, encore moins la comptabilité, et je n’ai aucune idée de tout ce qu’il va falloir apprendre.

Mais sur l’aspect humain, une bonne partie de mes inquiétudes du premier jour avaient déjà disparu.

Découvrir le métier avant de toucher au code

La première semaine était assez cadrée, avec plusieurs sessions pour découvrir Indy, les équipes et les différents métiers.

Ce que j’ai apprécié, c’est que les présentations n’étaient pas enchaînées toute la journée. Il y avait du temps entre chaque présentation pour assimiler, échanger avec les gens ou simplement commencer à explorer un peu par moi-même.

On a commencé par le setup IT et la découverte des outils, puis les différentes présentations se sont enchaînées progressivement. Une des premières nous a aussi permis d’échanger avec le CEO autour de la culture de l’entreprise et de poser nos questions assez librement.

Et au milieu de tout ça, il y avait aussi des moments beaucoup plus concrets.

Les premiers jours, je ne code pas encore vraiment.

À la place, je passe notamment du temps en binôme avec des collègues d’autres équipes pour découvrir leur quotidien de l’intérieur.

Côté Sales, je me retrouve directement sur une vraie situation avec un client.

Je suis simplement là pour observer et pourtant, au fil de l’appel, je me sens complètement embarqué dans l’échange. À la fin, quand tout se termine bien, on célèbre ensemble.

Je n’avais littéralement rien fait 😄, mais j’avais quand même l’impression d’avoir un peu participé.

Avec l’équipe Care, c’est différent.

Pas d’appel cette fois. On travaille ensemble sur de vrais tickets, notamment autour de la catégorisation de transactions.

Autant dire qu’à ce moment-là, mes connaissances en comptabilité sont assez limitées.

Et c’est justement là qu’un truc me marque.

Face à certaines questions, personne n’essaie de faire semblant de connaître la réponse.

C’est plutôt quelque chose comme

“Je ne sais pas exactement non plus. On va chercher.”

Et on cherche ensemble.

Ça m’enlève assez vite une pression que je m’étais mise tout seul, celle de devoir comprendre rapidement tout le métier et d’avoir une réponse à tout.

Bonne nouvelle, ce n’était visiblement pas nécessaire.

Prendre le temps de comprendre avant de vouloir aller vite

Pendant la première semaine, mon manager est présent sans être omniprésent.

J’ai les différentes sessions prévues avec ma promo et, entre deux rendez-vous, je reste assez libre d’organiser mon temps. Il prend régulièrement des nouvelles par message et reste disponible si j’ai besoin de quelque chose.

À partir de la deuxième semaine, j’ai naturellement envie de commencer à coder et de montrer assez vite ce que je sais faire.

Mon manager m’encourage plutôt à prendre mon temps.

En gros, il n’est pas inquiet sur le fait que je finirai par montrer mes compétences techniques. Ça viendra. Pour l’instant, le plus important, c’est surtout de prendre le temps de connaître l’équipe, créer du lien, puis de comprendre progressivement le produit, le métier et la codebase.

Et surtout, il n’y a pas de compteur de PR à remplir pour valider mon arrivée.

Il m’avait aussi préparé une checklist pour guider mes premières semaines et mes premiers mois. Je pouvais avancer à mon rythme tout en sachant ce qu’il était important de découvrir.

Côté code, je commence petit.

Une première tâche pour découvrir tout le flow. Comprendre le besoin, créer le ticket, coder, passer par la review puis merger.

Ensuite une tâche un peu plus conséquente, puis une autre.

Les premières reviews me permettent aussi de découvrir certaines conventions internes et de commencer à parcourir les ADR qui documentent une partie des choix d’architecture.

Il y a quand même des choses que j’aurais aimé avoir plus tôt.

La présentation globale de l’architecture, par exemple, arrive environ trois semaines après mon arrivée.

Pour moi, c’était trop tard, parce qu’entre-temps j’avais déjà commencé à toucher à plusieurs parties de la codebase sans vraiment avoir une vision globale de la façon dont tout s’articulait.

J’aurais aimé avoir cette vue d’ensemble beaucoup plus tôt, ne serait-ce que pour mieux comprendre où je mettais les pieds. Certaines conventions, je les ai aussi découvertes au moment où elles m’étaient signalées en code review.

Ce sont des points que j’ai remontés ensuite.

Mais assez rapidement, un constat devient clair. Techniquement, ça va.

Ce qui me demande beaucoup plus d’énergie, c’est le métier.

La comptabilité, la fiscalité, les règles derrière certaines fonctionnalités… comprendre pourquoi on fait quelque chose est parfois beaucoup plus compliqué que de comprendre comment le coder.

Spoiler, quatre mois plus tard, je ne suis toujours pas expert-comptable 😅.

Mais les sujets deviennent progressivement moins opaques.

Et surtout, je commence à être impliqué plus tôt dans les sujets, avant même qu’ils arrivent sous forme de tâches prêtes à développer.

Garder un regard neuf avant qu’il ne disparaisse

Après quelques semaines, on me demande de remplir un rapport d’étonnement.

Le principe est de noter ce qui m’a plu, ce qui m’a surpris, ce qui m’a manqué et ce que j’aurais aimé voir autrement.

Le faire tôt est assez important.

Quelques mois plus tard, les petites frictions du début deviennent vite “normales” et on finit par les oublier.

J’en ai profité pour partager ce qui m’avait manqué pour prendre mes repères côté technique.

Mes retours ont été bien accueillis, notamment celui sur l’architecture, avec l’idée de faire évoluer les choses pour les prochains onboardings.

J’ai trouvé ça assez sain.

Je pouvais avoir une expérience globalement très positive et quand même dire “ça, je pense qu’on peut le faire mieux.”

Les deux n’étaient pas incompatibles.

Ne plus seulement coder le sujet

Après deux ou trois mois, je commence à être plus autonome sur la partie technique.

Je connais mieux l’équipe, je sais davantage où chercher l’information et j’ai assez de contexte pour commencer à m’impliquer plus tôt dans les sujets.

C’est à ce moment-là que je demande à devenir Informed Captain sur l’un d’eux.

Chez Indy, l’Informed Captain est le développeur référent d’un nouveau sujet. Il est impliqué dès le début avec le PM, le design et les autres personnes concernées, avant que tout se transforme en tickets à développer.

Sur ce sujet, une première solution avait été imaginée.

Elle répondait au besoin, mais demandait aussi pas mal de travail avant de pouvoir obtenir un premier retour des utilisateurs.

Je propose une approche plus simple. Sortir une première version plus rapidement, observer comment elle est utilisée, puis décider de la suite avec davantage de feedback.

La proposition est challengée. On discute avec le PM et le design des avantages, des limites, de ce qu’on gagne et de ce qu’on laisse de côté. Et finalement, c’est cette approche qu’on retient.

Ce qui m’a surtout marqué n’était pas d’avoir eu raison.

C’était de voir que je pouvais arriver avec une proposition différente, la défendre, me faire challenger et participer réellement à la décision alors que ça ne faisait que quelques mois que j’étais là.

Mon ancienneté n’était pas un argument dans la discussion.

À ce moment-là, je ne découvrais plus seulement comment l’équipe travaillait.

Je commençais vraiment à participer à la réflexion.

Et puis le terrain de jeu s’est un peu agrandi

Avec le temps, je commence aussi à toucher à des sujets qui dépassent le périmètre de mon équipe.

Et c’est là qu’une rencontre du premier jour revient.

Vous vous souvenez du développeur rencontré près du piano ?

Quelques semaines plus tard, je dois justement travailler avec lui sur un sujet cross-équipe.

Cette fois, on ne parle plus musique entre deux réunions 😄.

Le fait d’avoir déjà créé ce lien rend les choses beaucoup plus simples. Je sais vers qui aller, et je n’ai pas cette impression de débarquer chez quelqu’un d’une autre équipe uniquement parce que j’ai besoin de quelque chose.

Dans le même temps, mon manager m’encourage à regarder du côté des guildes.

Je choisis de rejoindre une guilde transverse consacrée à la Developer Experience, la DevX. Chez Indy, une guilde regroupe des personnes de différentes équipes qui consacrent quelques heures par semaine à un sujet commun.

Je ne savais pas vraiment ce qu’il fallait pour rejoindre une guilde. La réponse était assez simple. Avoir envie de contribuer.

Il y a différents sujets disponibles et je peux aller vers ceux qui m’intéressent, creuser et commencer à contribuer. Et si j’ai besoin d’aide, je peux travailler avec des développeurs qui ont beaucoup plus de contexte et d’expérience sur ces problématiques.

C’est aussi ce que je cherchais, pouvoir travailler de temps en temps sur des sujets purement techniques, en dehors des problématiques produit de mon équipe.

À ce stade, mon quotidien commence donc à dépasser assez naturellement le cadre de ma squad, entre mon équipe, des sujets cross-équipe et la DevX.

Quatre mois plus tard

Pendant mes entretiens, j’avais posé pas mal de questions sur la manière de travailler chez Indy.

Quatre mois plus tard, je pouvais enfin comparer ce qu’on m’avait raconté avec ce que j’avais réellement vécu.

Tout n’était évidemment pas parfait.

Il y a des choses que j’aurais aimé découvrir plus tôt, et il me reste encore beaucoup à apprendre côté métier.

J’ai trouvé des gens avec qui je peux poser une question sans avoir peur d’être jugé parce que je viens d’arriver ou parce que je ne maîtrise pas encore le sujet.

On m’a laissé le temps de comprendre avant de me demander de délivrer, puis on m’a fait confiance quand j’ai voulu prendre plus de responsabilités.

Au fond, mes quatre premiers mois ont surtout ressemblé à ça. Trouver ma place, prendre le temps de comprendre, puis élargir progressivement l’espace dans lequel je peux contribuer.

Et si je reviens à la question que je me posais en arrivant à Lyon ce premier jour, oui, j’ai trouvé ma place.

Et au-delà de ça, ce que j’ai découvert au fil de ces quatre mois ressemble beaucoup à ce qu’on m’avait présenté pendant les entretiens.

Avec, en bonus, beaucoup plus de comptabilité que prévu 😄.