“Sur une journée type, je code peut-être 10 % du temps”, quelle réalité derrière le mot IA Interview de Cédric Locchi
J’ai eu l’occasion d’échanger avec Cédric qui s’est porté volontaire pour me décrire l’envers du décor de l’IA en me racontant son quotidien mais aussi en me partageant ses opinions, sa vision, ses craintes pour le futur. J’ai adoré la spontanéité de l’échange ainsi que les éléments tangibles qui permettent de se forger une opinion réaliste.
Il y a eu aussi beaucoup d’informations pertinentes à destination de la population junior dans la tech qui se pose certainement pléthore de questions.
Voici l’intégralité de l’interview :
Peux-tu te présenter en quelques mots ?
Je suis Tech Lead Front, spécialisé sur la stack frontend dont Angular. J'interviens sur tout ce qui touche à l'UI, l'UX, et je fais aussi du mentorat : je monte en compétences les juniors de l'équipe.
À quoi ressemble ta journée type aujourd'hui, comparée à celle d'il y a deux ou trois ans ?
L'augmentation de productivité, sans hésitation. Avant, je faisais des features en réfléchissant à l'architecture en amont. Aujourd'hui, j'ai fait un x10 en productivité sur les six derniers mois. J'ai sorti autant de features en six mois qu'en un an et demi de dev avant.
Ma journée : peu de réunions, c'est déjà bien. Le matin, c'est de la réflexion et de la planification : comment j'adresse le problème, comment je le traite.
Ensuite vient l'exécution : je lance l'implémentation avec Claude ou GPT, selon les cas.
Pendant ce temps, je travaille sur la feature suivante, je rédige des specs. Une fois l'implémentation terminée, je fais une revue : je regarde l'impact sur la codebase, ce qui a été créé ou modifié. Si quelque chose me surprend, je lance l'application en local, je teste à la main, je vérifie qu'il n'y a pas de régression. Parfois ça révèle de la dette technique qu'on avait laissée traîner.
Sur une journée type, je code peut-être 10 % du temps pour des ajustements simples, ou quand l'IA a mal compris une consigne et qu'il vaut mieux corriger soi-même que réexpliquer.
Quel est ton niveau d'expérimentation avec les outils IA, et lesquels utilises-tu au quotidien ?
Sporadique, mais intense. Au bureau, on utilise GitHub Copilot, sans restriction de modèle : environ 300 dollars de budget par développeur. On est en train de mesurer le vrai coût des tokens face au temps gagné.
De mon côté, j'utilise Claude Code depuis presque un an, à fond. J'ai commencé pour me former au développement mobile iOS et Swift ; aujourd'hui j'ai quatre applications qui sortent sur le store. Je me base sur des méthodologies comme BMAD, qui me donnent une vision produit, marché et concurrence que je n'ai pas naturellement en tant que développeur pur.
Je répartis les modèles selon la tâche :
- Haiku pour tout ce qui est cadré par des skills, réflexion produit, étude de marché, parce que ça va vite et que ça ne demande pas de réflexion profonde.
- Sonnet pour la planification standard.
- Opus pour les vraies problématiques d'architecture.
Et dans tous les cas, c'est toujours Sonnet qui écrit le code final : une fois le plan posé, c'est un chemin A vers B, inutile de consommer des tokens avec un gros modèle pour ça.
As-tu le sentiment de faire un métier fondamentalement différent ? Es-tu encore programmeur, ou plutôt chef d'orchestre ?
Je n'ai jamais eu d'attachement au code. Pour moi, c'est un langage qui résout un problème, pas une fin en soi. Le problème, aujourd'hui, on le résout en dialoguant avec l'IA et en planifiant.
Le code, on a toujours cherché à l'automatiser, à le réduire.
Un bon ingénieur résout des problèmes, le langage qu'il utilise, ce n'est pas très grave. Le code est un outil, l'IA est un outil. Si l'IA peut m'éviter d'en écrire, ce n'est pas plus mal.
Y a-t-il des domaines où tu refuses d'utiliser l'IA, par éthique, par sécurité, par plaisir de coder ?
Non. La sécurité du code, ce n'est pas une question de qui l'écrit, c'est une question de connaissance et d'expérience. Si la planification est réfléchie, la faille ne sera pas là, que ce soit l'IA ou moi qui écrive le code. Si la planification est mauvaise, la faille y sera de toute façon.
En revanche, sur le mobile, iOS, Swift, je me réserve parfois une feature à coder moi-même. Pas parce que ça me manque, mais pour me faire plaisir, et pour me recentrer. Le soir, c'est mon garde-fou : je sais que si je n'ai pas fini, ce n'est pas grave, je continuerai demain. Ça marque la limite entre le travail et ma vie de famille.
Quel constat fais-tu sur la composition des équipes et la place des juniors ?
Autour de moi, à Sophia Antipolis, on a une forte culture tech. Beaucoup d'entreprises embauchent encore des juniors. On a pris trois alternants récemment, dont un spécialisé en IA pour l'intégrer à nos produits. Mais sur les réseaux sociaux, oui, on voit clairement une raréfaction.
Cette raréfaction t'inquiète-t-elle pour l'avenir de la profession ?
L'IA a accéléré le problème, mais elle n'en est pas la cause racine. Depuis le Covid, l'argent s'est raréfié, il y a moins de budgets, moins de projets.
Pourtant le flux de juniors qui sortent des écoles et des bootcamps n'a pas ralenti. Le marché est inondé, il ne peut pas se réguler. L'IA écrème au moins 50 % de ces profils, parce qu'ils n'ont pas les compétences qu'on attendrait aujourd'hui d'un junior épaulé par l'IA.
Quel conseil donnerais-tu à un junior pour sortir du lot dans ce contexte ?
La vraie plus-value d'un junior aujourd'hui, c'est la théorie : c'est elle qui permet de driver correctement l'IA. Un junior qui maîtrise la clean architecture, qui sait construire une vraie architecture logicielle et le démontrer avec un projet concret, s'en sort. Je connais d'anciens élèves que j'ai mentorés qui ont passé six ou sept mois à travailler uniquement la théorie : architecture, cloud, asynchrone. Résultat : des produits utilisés, des chiffres à montrer, et un job trouvé en start-up grâce à ça.
Quelle est selon toi la vraie valeur ajoutée d'un développeur aujourd'hui ?
La compréhension du business. Avec l'IA, tout va vite : on planifie, on exécute, on planifie, on exécute, et on peut vite s'égarer. Il faut se raccrocher à pourquoi on fait les choses, à l'impact fonctionnel pour le client, comprendre le besoin réel derrière une demande.
Un très bon développeur, sans appétence produit, se fait manger par un product manager qui connaît le métier et sait cadrer une IA.
Une expertise technique sans expertise fonctionnelle, c'est voué à l'échec parce que sur le pur technique, l'IA est déjà meilleure que nous.
Prends-tu toujours autant de plaisir à exercer ce métier ?
Oui, parce que ce que j'aime, c'est résoudre des problèmes, pas écrire du code. J'ai une réflexion d'ingénieur, pas de codeur. Je comprends que ceux dont le kiff est d'écrire du code se sentent moins à leur place aujourd'hui. Mais ce n'est pas mon cas.
Entre gain de productivité et perte du craft manuel, quel est ton ressenti ?
Je ne pense pas qu'on perde le craft. L'artisanat, c'est l'ingénierie : résoudre un problème complexe de la façon la plus simple et la plus fiable possible. Ça, on peut le faire avec l'IA. Ce qui compte, c'est la culture qu'on transmet.
Nos juniors, au début, envoyaient des pull requests de 80 fichiers et 7000 lignes, un enfer à relire. Depuis qu'on leur enseigne la théorie de l'architecture, leurs PR font 200 lignes, bien découpées, bien pensées.
La différence entre un junior formé à la théorie et un junior livré à lui-même avec l'IA est énorme.
Comment te projettes-tu dans trois à cinq ans ? Quelles sont tes craintes ?
Aucune vraiment. Travailler avec des agents IA, ça s'apparente déjà à du management. Je compte évoluer vers du management technique : VP Engineering, CTO, ou staff engineer. Je vais naturellement me détacher du code.
Es-tu un cas à part, ou cette évolution est-elle généralisée ?
Il y a une vraie cassure entre deux profils : le codeur, qui code sans trop se poser de questions parce que l'IA écrit tout à sa place, et l'ingénieur, qui conçoit. Cette cassure se joue surtout dans la formation.
Même dans une école d'ingénierie plutôt novatrice comme Polytech Sophia, on enseigne encore des technos anciennes à des étudiants qui, dans leur immense majorité, feront du web ensuite. Il faudrait revoir complètement la scolarité : comment on inculque l'usage des outils, et surtout l'éthique de leur usage. Aujourd'hui, beaucoup de profs interdisent l'IA en cours : résultat, les élèves la consultent en cachette sur leur téléphone plutôt que de l'utiliser de façon assumée et cohérente. Faire écrire du code à la main en 2025, ça n'a plus de sens.
Un mot de la fin, un conseil, un métier émergent à surveiller ?
Ce n'est pas vraiment un métier émergent, mais un changement de posture : le produit devient autonome. Un product manager qui maîtrise les bonnes méthodologies, BMAD, spec-driven, peut créer une application sans passer par la technique pure. Ce qui compte pour un junior, c'est de comprendre ces méthodologies, de savoir cadrer un besoin en spec.
Si je devais dire une seule chose à un junior aujourd'hui : ne te focalise pas sur le code, il est jetable. Focalise-toi sur l'architecture, la théorie, et surtout la compréhension du besoin client, apprends à faire parler le client, à schématiser ce qu'il te décrit, pour ensuite t'approprier les outils, IA, agents de code, peu importe lequel, et le retranscrire correctement.
Cet échange avec Cédric offre une grille de lecture d'une clarté rafraîchissante sur la transformation de nos métiers tech face à l'IA générative : Le code est devenu un détail d'exécution. Quand un Dev/Tech Lead consacre 90 % de son temps à la stratégie, à la planification et à l'architecture pour ne coder plus qu'à 10 %, le message est limpide : la valeur n'est plus dans la syntaxe, mais dans la résolution de problèmes. Par ailleurs, l'ambition Produit prend le dessus : technique et vision business sont désormais indissociables. Sans compréhension fine du besoin utilisateur et du marché, l'expertise technique pure risque d'être supplantée par des profils produit sachant piloter l'IA.
Shirley Almosni Chiche
