J’ai toujours été attiré par l’informatique et par le fait de créer des choses concrètes. Ce qui me plait dans le développement, c’est de partir d’une idée et de la transformer en un outil ou une application que des personnes vont réellement utiliser au quotidien.
Concrètement, sur quoi travailles-tu aujourd’hui ?
Aujourd’hui, je suis développeur fullstack sur un outil qui centralise la gestion des dossiers de facturation liés aux révisions des moteurs (shop visits), pour un équipementier aéronautique.
J’interviens sur l’ensemble de l’application : le front-end (React, TypeScript), le back-end (NestJS, PostgreSQL), mais aussi sur l’architecture de l’application et de la base de données, jusqu’au déploiement.
Cet outil est directement intégré au quotidien des différentes équipes qui interviennent dans la facturation. Il leur permet de suivre un dossier de A à Z — depuis sa création et la collecte des documents nécessaires jusqu’à la validation et l’émission de la facture.
J’ai par exemple travaillé sur une vue d’ensemble permettant de suivre les dossiers par équipe et par niveau de priorité, sur l’identification des points bloquants, sur les écrans de suivi des différentes étapes de leur traitement, ou encore sur des fonctionnalités d’import et d’export des dossiers liés aux révisions moteurs.
L’objectif est de remplacer un processus jusque-là dispersé entre fichiers, emails et différents outils par un point d’entrée unique et fiable où chacun peut voir où en est un dossier et ce qu’il reste à faire.
Et le projet commence déjà à porter ses fruits : avant la mise en place de l’outil, les équipes géraient environ 15 factures par semaine. Aujourd’hui, elles en traitent plutôt 20 — ce n’est que le début, l’outil continue d’évoluer pour simplifier encore davantage leur travail au quotidien.
Quels sont les principaux défis techniques ou organisationnels que tu rencontres ?
Le principal défi, c’est de faire évoluer une application qui intègre de nombreuses règles métier (accumulées au fil des années) sans casser ce qui fonctionne déjà.
Sur cet outil, par exemple, le dossier de facturation associé à une révision moteur (shop visit) peut suivre un parcours différent selon le contrat, le client ou le type de facturation (acompte, garantie…). Chaque dossier passe par différents statuts et une succession d’échéances, avec des équipes qui interviennent à des moments précis. Une petite modification peut donc avoir des répercussions sur plusieurs fonctionnalités et plusieurs utilisateurs.
Dans ce contexte, une grande partie du travail se joue avant même de commencer à développer. Je dois comprendre le besoin, lire les spécifications, échanger avec les équipes et anticiper les différents cas possibles pour mesurer les impacts d’une évolution.
Ensuite, je privilégie les petites évolutions plus faciles à tester, plutôt que de modifier plusieurs éléments en même temps. Je veille aussi à structurer le code et la base de données pour faciliter les évolutions futures et je m’appuie sur des tests pour détecter les régressions avant qu’elles n’atteignent les utilisateurs.
De quelle réalisation technique es-tu le plus fier ?
Je suis particulièrement fier du travail réalisé sur la recherche et l’affichage de grandes quantités de données. Avec plusieurs milliers de dossiers et de nombreux critères (statut, client, échéances, rôles…), les temps de réponse commençaient à s’allonger dès que les utilisateurs voulaient filtrer ou trier les informations.
Plutôt que de chercher uniquement à améliorer l’existant, j’ai repensé l’architecture de cette fonctionnalité pour qu’elle puisse absorber l’augmentation du volume de données dans le temps. Le filtrage, le tri et la pagination sont désormais gérés côté serveur, avec une base de données structurée et des requêtes optimisées.
L’enjeu n’était pas seulement d’améliorer les temps de réponse mais de concevoir une solution capable de rester performante à mesure que le nombre de dossiers augmente. Pour les équipes, le résultat est concret : elles retrouvent un dossier en quelques clics, même parmi plusieurs milliers de dossiers.
Quel impact l’Intelligence Artificielle a-t-elle sur ta façon de travailler aujourd’hui ?
L’IA est devenue un véritable compagnon de travail au quotidien, mais pas un remplaçant. Je l’utilise surtout pour gagner du temps et explorer différentes pistes tout en gardant la maîtrise des choix techniques.
Je travaille principalement avec Cursor et différents modèles d’IA comme GPT ou Claude, que je choisis en fonction de la tâche à réaliser. Pour résoudre un bug, je donne à l’IA le contexte : l’erreur rencontrée, le comportement attendu et la partie du code concernée. Elle m’aide à explorer différentes pistes, mais je vérifie toujours ses propositions dans le code avant de les valider. Pour la documentation, l’IA m’aide à structurer une première version que je retravaille ensuite. Pour la génération de code, je m’en sers surtout pour générer du code standard et répétitif ou pour comparer différentes approches techniques — rarement en copier-coller direct.
Je fais particulièrement attention lorsqu’il s’agit de choix structurants comme l’architecture de la base de données. Elle doit être bien pensée dès le départ pour garantir un accès rapide et efficace aux données même lorsque leur volume augmente fortement.
L’IA peut proposer du code générique mais elle ne prend pas en compte toutes les contraintes du projet et du métier. Mon rôle est de m’assurer que ses propositions sont réellement adaptées : je relis, je teste et je challenge — parce qu’un mauvais choix de structure aujourd’hui peut rapidement compliquer les évolutions de demain.
Expertise
Ingénierie Logicielle
Qu’est-ce qui fait, selon toi, un bon développeur aujourd’hui ?
Pour moi, un bon développeur ne se limite pas à maîtriser la technique. Il doit surtout comprendre le besoin métier et les conséquences de ce qu’il développe.
Sur l’outil dont on vient de parler par exemple, une condition mal définie sur un statut de facturation peut indiquer qu’un dossier est prêt à être facturé alors qu’il manque encore une validation — avec un impact direct sur le travail des équipes. C’est pour cela que la rigueur est essentielle : vérifier, tester et surtout poser des questions quand une règle métier n’est pas claire.
Il faut aussi être curieux et chercher à comprendre l’origine d’un problème, plutôt que de corriger uniquement ce qui est visible. Et lorsqu’on développe une solution, il faut penser à la suite : est-ce que le code sera compréhensible et facile à faire évoluer dans six mois, y compris par quelqu’un d’autre ?
Le développement est aussi un travail collectif. Echanger avec les équipes métier sur un cas concret avant de livrer permet souvent d’identifier un problème ou un besoin qui n’était pas évident au départ.
Ce qui fait la différence, c’est aussi de savoir prendre un peu plus de temps au bon moment pour poser une question, écrire un test ou améliorer une partie du code plutôt que d’aller vite et de créer des problèmes qui devront être corrigés plus tard.
Qu’est-ce qui te plaît le plus dans ton métier ?
Ce qui me plaît le plus, c’est résoudre des problèmes et apprendre en permanence. Chaque projet apporte de nouveaux défis, techniques ou fonctionnels, et j’aime chercher une solution puis voir concrètement ce qu’elle apporte aux utilisateurs.
Sur cet outil par exemple, ce qui me satisfait le plus, c’est quand une équipe me dit qu’elle retrouve rapidement un dossier ou qu’elle identifie immédiatement ce qui bloque — des choses qui prenaient avant beaucoup de temps et d’allers-retours. Ce n’est pas spectaculaire à l’écran, mais au quotidien, ça change vraiment la façon de travailler.
Pour continuer à apprendre, je me forme beaucoup par moi-même : je consulte la documentation, j’explore le code existant, et surtout j’expérimente.
J’ai aussi des projets personnels d’applications mobiles pour lesquels je fais générer l’intégralité du code par l’IA. C’est pour moi un véritable terrain d’expérimentation : je peux tester différentes approches, voir jusqu’où l’IA peut aller, comprendre ses limites, me tromper et recommencer sans les contraintes d’un projet client. Essayer, échouer, ajuster et recommencer : c’est aussi comme ça que je progresse.
Qu’est-ce que tu apprécies au sein d’ATLANSE ?
Ce que j’apprécie chez ATLANSE, c’est la confiance et l’autonomie que l’on m’accorde. Sur ma mission actuelle par exemple, je peux prendre en charge des sujets structurants notamment autour de l’architecture et être force de proposition sur les choix techniques.
J’apprécie aussi la proximité avec l’équipe ATLANSE. Des événements sont régulièrement organisés notamment autour de sujets d’actualité et permettent de se retrouver et de créer du lien au-delà des missions. Les échanges restent simples et directs, on se sent accompagné, et on sait que l’équipe est présente quand on en a besoin.
Quels conseils donnerais-tu à quelqu’un qui souhaite se lancer ?
Je lui conseillerais avant tout de pratiquer régulièrement et de développer des choses concrètes. Suivre des tutoriels permet d’acquérir les bases, mais c’est lorsqu’on essaie de construire soi-même une fonctionnalité complète – un formulaire, un appel à une API, la gestion d’une erreur – que l’on commence vraiment à comprendre comment les différentes briques fonctionnent ensemble.
Je conseillerais aussi de ne pas rester uniquement sur des projets simples. Travailler sur une application avec des règles métier, différents utilisateurs ou plusieurs étapes dans un parcours permet de se confronter à des problématiques beaucoup plus proches de celles que l’on rencontre en entreprise. Sur un projet personnel, cela oblige aussi à faire ses propres choix et à structurer soi-même son application.
Enfin, il faut rester curieux. Quand je ne comprends pas un choix technique, je demande pourquoi. Et je trouve intéressant d’explorer différents sujets (front, back, base de données) pour mieux comprendre l’application dans son ensemble.
Et surtout, n’aie pas peur de te tromper : c’est en expérimentant et en cherchant à comprendre que l’on progresse le plus.
