Les 90 premiers jours : Guide pas à pas pour l’ingénieur logiciel
Vous avez été sur le terrain.
Vous avez peaufiné votre CV jusqu’à ce qu’il brille. Vous avez renforcé vos compétences et vos certifications.
Vous avez soigné votre GitHub, étudié les questions de conception de systèmes jusqu’à en voir double, et appuyé sur « postuler » bien plus de fois que vous ne souhaitez compter.
Have an account? Log In
Vous avez affronté l’épreuve de l’entretien — tableaux blancs, exercices à la maison, silences gênants, tout y est passé. Vous avez amélioré vos compétences tout en gardant votre sang-froid.
Et puis… la lettre d’embauche est arrivée. Vous avez décroché le poste ! Le vrai travail commence maintenant.
Car si recruter est difficile, réussir son intégration l’est encore plus. C’est à ce moment que vous passez du statut de candidat à celui de contributeur, et que vos premières impressions deviennent durables. Vos 90 premiers jours poseront les bases de tout ce qui suivra.
Dans ce guide, je vais vous expliquer comment démarrer fort en tant que nouvel ingénieur logiciel, avec des conseils pratiques de deux professionnels chevronnés du secteur qui ont vécu cette expérience, en connaissent les ficelles et savent ce qui fonctionne. Mais commençons d’abord par une analyse lucide de ce que cela veut réellement dire être ingénieur logiciel aujourd’hui.
Qu’est-ce qu’un ingénieur logiciel ?
Oh là là, par où commencer ? Honnêtement, on pourrait écrire un livre sur le sujet, notamment parce que le terme est parfois utilisé comme un fourre-tout englobant de nombreux rôles potentiels à chaque phase du cycle de développement logiciel. D’autres intitulés sont donc également pertinents ici, comme développeur ou programmeur. Nous utilisons ici « ingénieur logiciel » comme terme générique.
Voici une définition succincte de l’ingénierie logicielle, proposée par la Michigan Technological University pour nous guider : « L’ingénierie logicielle est la branche de l’informatique qui concerne la conception, le développement, le test et la maintenance d’applications logicielles. Les ingénieurs logiciels appliquent les principes de l’ingénierie et leurs connaissances des langages de programmation pour créer des solutions logicielles destinées aux utilisateurs finaux. »
Pour résumer simplement : les ingénieurs logiciels construisent des objets numériques pour les personnes comme pour les machines. Au lieu d’un marteau et de clous, ils utilisent du code et tout un arsenal d’outils comme Git et d’autres composants.
Il faut également souligner l’une des raisons pour lesquelles tant de personnes souhaitent devenir ingénieur logiciel : c’est un métier qui peut bien payer. Le site spécialisé Glassdoor fixe la rémunération totale médiane des ingénieurs logiciels à 147 000 $ par an (dernière vérification : 28 avril 2025), même si ce chiffre pourra varier en fonction de l’expérience, de la localisation et du secteur.
Passons maintenant à des conseils et idées concrètes pour bien démarrer.
Les 30 premiers jours
Dans notre article compagnon consacré aux carrières en cybersécurité, nous avions noté que les 30 premiers jours sont essentiellement consacrés à l’apprentissage. Cela comprend tout : bases de code, outils, nouvelles têtes et nouveaux espaces. Rien ne change ici, même si quelques ajustements s’imposent.
Conseil n°1 : Toutes les piles technologiques ne se valent pas
Votre prise de poste doit autant passer par l’apprentissage des personnes et des processus que par celui du code ou de la pile technologique.
« D’après mon expérience dans les grandes entreprises, il est plus important de comprendre les personnes [et] les processus que l’architecture du code, » explique Justin Garrison, Head of Product chez Sidero Labs. Avant d’occuper ce poste, Justin a travaillé comme Senior Developer Advocate chez AWS et a occupé différents postes d’ingénieur chez Disney, dont celui d’ingénieur logiciel senior.
Conseil n°2 : Comprendre comment l’entreprise génère des revenus
Pour maximiser votre valeur, vous devez comprendre comment l’organisation crée sa valeur.
« En plus d’assimiler la pile technique et les besoins, les ingénieurs devraient aussi comprendre comment l’entreprise crée de la valeur et est rémunérée, » nous confie Chris Carter, Principal Product Manager chez NetApp Instaclustr. Avant d’occuper ses fonctions actuelles, Chris avait débuté dans l’entreprise comme ingénieur développement senior puis lead d’équipe d’ingénierie. Il poursuit :
« Abonnements directs ? Équipe de vente et contrats sur mesure ? Audience et publicité ? Comprenez comment l’entreprise mesure sa réussite et comment on passe du code au KPI. »
Développez cette compréhension le plus tôt possible. Les ingénieurs logiciels capables de relier leur code à la santé financière de leur entreprise ne perdront pas de leur valeur de sitôt.
« En comprenant comment l’entreprise mesure son propre succès, vous pouvez vous positionner pour participer à la génération de ce succès et contribuer au résultat net, » dit Chris.
Conseil n°3 : Clonez le dépôt, mais ne précipitez pas le commit
Bien sûr, vous êtes pressé de faire votre première PR. Mais traitez la base de code comme un organisme vivant : observez ses motifs, comprenez son anatomie, et posez des questions avant d’opérer. Utilisez les fonctionnalités de navigation de code de votre IDE, les commandes grep ou la recherche dans le dépôt pour suivre comment les données et la logique traversent le système.
Et si vous êtes bloqué ? Essayez de reproduire le comportement localement puis de le suivre étape par étape. Les débogueurs sont sous-estimés, et l’astuce du canard en plastique fonctionne toujours.
Astuces de pro : Consultez les dernières PR fusionnées pour comprendre le style de code, la culture de relecture et ce à quoi « terminé » ressemble réellement.
Les 60 premiers jours
L’une des meilleures façons de monter rapidement en compétences est d’être curieux, non seulement sur ce que fait le code, mais pourquoi il le fait ainsi.
Conseil n°4 : Demandez, « Pourquoi cela a-t-il été construit de cette manière ? »
Le code hérité peut ressembler à des spaghettis, mais il y a souvent du contenu dans la sauce. Les contraintes d’un service désormais à la retraite, un compromis de performance, une exigence métier d’une fonctionnalité abandonnée : ces choix ont une histoire. Connaitre cette histoire vous aide à éviter de proposer quelque chose qui a déjà été essayé (et échoué), et renforce votre crédibilité.
Commencez par la documentation interne (même si elle n’est plus à jour). Puis demandez à un collègue de vous expliquer quelque chose de déroutant et traitez-le comme un co-auteur de l’histoire du système.
« Quelles décisions sont encodées dans ce code ? » est une meilleure question que « Pourquoi ce code est-il mauvais ? »
Conseil n°5 : Identifiez les « règles tacites » de votre équipe
Toute organisation d’ingénierie en possède. Peut-être que l’équipe préfère les RFC dans Notion à la place des tickets Jira, ou que tout le monde effectue les déploiements le jeudi, ou que les tests unitaires sont optionnels—mais que les tests end-to-end sont sacrés.
Ces normes ne figurent pas toujours dans un manuel, mais elles façonneront votre succès tout autant que vos compétences en codage. Surveillez les habitudes Slack, étudiez les messages Git, et demandez à vos collègues ce qu’ils auraient aimé savoir à leur arrivée.
Conseil n°6 : Continuez à rencontrer – et à apprendre des – gens
Justin de Sidero Labs avance que rencontrer les gens aide les ingénieurs à comprendre comment les systèmes s’articulent au-delà du code : « À la fin de ces réunions, il était beaucoup plus facile de comprendre pourquoi les systèmes ont l’aspect qu’ils ont. »
Cela procure toutes sortes de bénéfices indirects, comme réduire votre stress en lisant du code qui ne paraît pas logique au premier abord. Si un humain l’a écrit, il a probablement eu une raison de le faire ainsi – des paramètres organisationnels, des contraintes de temps, etc.
Ce type de compréhension globale aide autant pour la culture d’équipe et la communication que pour l’empathie et la diplomatie lorsqu’il sera temps de proposer des améliorations.
Les 90 premiers jours
Vous avez pris vos marques : « Au bout de 90 jours, vous devriez avoir trouvé votre rythme et, avec un peu de chance, être prêt à prendre en charge des tâches plus importantes, » explique Chris de NetApp Instaclustr.
Cette dernière phase concerne vraiment la planification et le début de l’exécution. Où pouvez-vous
commencer à avoir un véritable impact ?
Conseil n°7 : Commencez à optimiser avec intention et impact
Après 90 jours, vous n’êtes plus simplement le « nouvel ingénieur » : vous devenez un contributeur à part entière. Cela signifie qu’il est temps de rechercher des opportunités pour améliorer les choses. Mais attention : toute amélioration n’est pas forcément pertinente, et tous les bugs ne méritent pas d’être corrigés.
« Il ne s’agit pas de dresser une liste de tout ce qui ne va pas, » dit Chris. « Il s’agit de comprendre l’entreprise, le client, le contexte — puis d’utiliser ces connaissances pour identifier des axes d’amélioration significatifs. »
Voici comment Chris et son équipe abordent cet état d’esprit :
- Pensez à l’amont : N’allez pas directement vers les solutions—commencez par rédiger des tickets clairs qui décrivent le problème.
- Priorisez intelligemment : Comprenez comment votre équipe évalue l’impact, l’effort et l’urgence. Un bug mineur d’UI sur un écran obsolète ? Ce n’est probablement pas une urgence.
- Esprit orienté client : Demandez-vous toujours : « Est-ce que cela comptera pour un utilisateur réel ? » Sinon, notez-le et passez à autre chose.
Une fois que vous avez assimilé les systèmes et la culture, commencez à repérer les tâches à fort effet de levier—celles qui réduisent la friction, améliorent la livraison ou renforcent l’expérience client.
« En livrant constamment un travail qui fait progresser les objectifs de l’entreprise, vous serez vite reconnu comme quelqu’un qui “a compris” — et en qui l’on peut avoir confiance pour des missions de plus grande envergure, » conclut Chris.
Astuce n°8 : Livrez quelque chose. Peu importe quoi. Mais appropriez-vous-le.
Au bout de 90 jours, vous n’avez pas besoin d’avoir réécrit un service clé ou lancé une nouvelle fonctionnalité en solo. Mais vous devez pouvoir montrer quelque chose, même minime, que vous avez livré et dont vous êtes responsable de bout en bout.
Cela peut être :
- Une correction de bug qui a réduit la friction pour les utilisateurs
- Un ajustement de pipeline CI/CD ayant accéléré les builds
- Une refonte du README qui a aidé le prochain nouvel arrivant
- Une optimisation backend qui a réduit de 50ms une requête courante
Ce n’est pas obligé d’être sexy—ça doit être utile. L’impact ne se mesure pas à l’apparence, mais à la fonction.
Mantra d’ingénieur : « Est-ce que j’ai amélioré la vie de l’équipe de 1% cette semaine ? »
Astuce n°9 : Concevez un backlog d’apprentissage personnel
Vous ne maîtriserez pas l’ensemble de la base de code, l’infrastructure et la logique métier en 90 jours. Ce n’est pas grave. Ce qui compte, c’est ce que vous faites après.
Créez un « backlog » personnel des compétences et connaissances à acquérir. Notez :
- Les parties du système que vous ne comprenez pas encore
- Les outils ou frameworks que vous souhaitez approfondir (par ex. Kubernetes, gRPC, Terraform)
- La dette technique ou les bizarreries à revisiter
Ensuite, priorisez une chose par sprint et cochez-la. Vous n’êtes pas seulement en train d’apprendre le système—vous concevez votre propre feuille de route de progression.
Abonnez-vous à la newsletter The CTO Club pour recevoir plus de guides pratiques pour vos 90 premiers jours dans un rôle tech !
