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.
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.
