IA et développement : pour Olivier Nouguier, l’enjeu est de garder le contrôle

Je connais Olivier Nouguier depuis pas mal de temps. J’ai eu l’occasion de le rencontrer notamment lors de l’événement Sunny Tech Montpellier. C’est un tech pur et dur, un fan de Scala et son expérience du monde de pure dev à l’IA  a été un pur régal à écouter. 

Dans cet échange, il revient sur l’évolution de son quotidien, entre accélération spectaculaire, prototypes réalisés en quelques heures et nouvelles formes d’agents autonomes, notamment dans le cadre de ses projets musicaux. 

Mais son enthousiasme s’accompagne d’une vigilance constante. Au-delà de l’usage gadget pour créer des choses amusantes et impressionnantes, selon lui, l’IA ne doit pas faire perdre aux développeurs la compréhension de ce qu’ils construisent. Expertise, capacité de recul et maîtrise des garde-fous pourraient ainsi devenir les compétences les plus importantes des prochaines années.

Tu as adopté très tôt les outils d’intelligence artificielle. Qu’est-ce qui a le plus changé dans ton quotidien de développeur ?

J’ai pris ce virage il y a déjà un ou deux ans. Je suis plutôt un early adopter, donc je me suis rapidement intéressé aux nouveaux outils et aux approches liées à l’IA et aux agents.

Mais cette adoption a aussi été très intense. À un moment, j’ai ressenti une vraie fatigue, parce que j’avais l’impression de perdre de la connaissance et du contrôle. Tout à coup, il fallait être capable de concevoir, de designer, de réfléchir à l’expérience utilisateur, parfois même sur des sujets que l’on ne maîtrisait pas vraiment.

J’ai donc pris du recul pendant plusieurs mois. J’avais besoin de me demander où je prenais encore du plaisir et quelle place je voulais donner à ces outils. Je reste très intéressé par leur puissance, mais je ne veux pas me disperser ni accumuler du code dont je ne comprends pas réellement le fonctionnement.

À quoi ressemble aujourd’hui ton utilisation quotidienne de l’IA ?

Aujourd’hui, l’IA est présente partout : dans les environnements de développement, dans les outils en ligne de commande, dans certains agents que j’utilise au travail comme dans mes projets personnels. Mais mon quotidien consiste surtout à réduire le périmètre et à contrôler davantage ce que je veux faire.

Je préfère avancer par petites étapes. Je peux commencer par utiliser un agent puissant pour réfléchir au produit et challenger le besoin, puis demander à un autre outil de m’aider à définir l’architecture technique. Ensuite seulement, je passe à l’implémentation.

Cette progression par incréments me permet de conserver une forme de maîtrise. Je ne suis pas encore convaincu par le fait de lancer une multitude d’agents en parallèle sans savoir exactement ce qu’ils vont produire. On entend beaucoup parler de systèmes capables de faire travailler plusieurs agents simultanément, mais la vraie question reste toujours la même : qu’est-ce qui arrive réellement en production ?

Pour quelles tâches les agents te semblent-ils les plus utiles ?

Je les utilise surtout lorsque j’ai un sujet à explorer ou à construire. Ils peuvent m’aider à clarifier le besoin, à concevoir une solution, à réfléchir à l’architecture, puis à produire une première implémentation.

Ce qui est intéressant, c’est de pouvoir découper le travail en plusieurs phases. On ne demande pas directement à l’outil de produire toute l’application. On lui demande d’abord de nous aider à comprendre ce que l’on veut faire, puis à définir comment le faire, et enfin à l’implémenter.

Cela permet également de mieux détecter les erreurs. Si l’on produit tout en une seule fois, on peut rapidement se retrouver avec une quantité considérable de code que l’on ne maîtrise pas. Or le code n’est pas seulement quelque chose que l’on génère : il faut ensuite le maintenir, le faire évoluer et corriger ses erreurs.

Tu sembles à la fois très enthousiaste et très prudent. Comment expliques-tu cette retenue ?

Il faut distinguer deux choses : s’amuser avec une technologie et l’utiliser pour construire quelque chose dont on devra assumer la responsabilité.

Pour expérimenter, l’IA est absolument fascinante. Je peux lui demander de produire en quelques heures une application liée à la musique, par exemple un outil pour visualiser des gammes et s’entraîner sur un instrument. Ce type de projet peut être réalisé très rapidement et c’est assez spectaculaire.

Mais je ne vais pas nécessairement maintenir cette application ensuite, parce que je ne sais pas toujours comment le code a été construit. L’outil peut générer quelque chose qui fonctionne, mais de manière extrêmement complexe. Le jour où un problème survient, il faut être capable de comprendre ce qui se passe.

Sur un projet jetable ou un prototype, ce n’est pas forcément grave. En revanche, dès que l’on touche à des sujets critiques, à des données sensibles ou à des enjeux de sécurité, le niveau d’exigence doit être complètement différent.

L’IA transforme-t-elle profondément le métier de développeur ?

Je ne ressens pas forcément que mon métier est devenu totalement différent, parce que je me préserve. Je garde des espaces dans lesquels je continue à réfléchir, à comprendre et à construire les choses moi-même.

Je pense qu’il y aura toujours de la place pour les personnes qui disposent d’une vraie expertise technique et qui travaillent en profondeur sur leur domaine. En revanche, les tâches de production les plus standardisées vont certainement être davantage automatisées.

Pour ma part, j’aime comprendre ce que je fais. C’est presque une déformation scientifique : je ne fais pas seulement les choses pour qu’elles fonctionnent, je veux savoir pourquoi elles fonctionnent.

À mes yeux, il reste notamment une place importante pour les développeurs qui conçoivent des composants ou des briques techniques. Dans ce cas, on connaît le périmètre fonctionnel, on comprend le domaine et on peut utiliser l’IA pour accélérer l’implémentation sans lui abandonner entièrement la direction du projet.

Quelle place accordes-tu à l’IA : assistant, agent ou véritable remplaçant ?

Pour moi, l’IA doit d’abord être un facilitateur. C’est quelqu’un, ou plutôt quelque chose, qui répond à mes questions. Je ne veux pas forcément qu’elle me donne des réponses que je n’ai pas demandées, car il faut conserver le contrôle du raisonnement.

Un agent autonome fonctionne différemment. Il peut tourner en permanence, accéder à une messagerie, consulter des outils, répondre à des demandes et enchaîner des actions. Dans certains systèmes, le modèle peut même générer du code, l’exécuter, observer le résultat, puis recommencer dans une boucle autonome.

C’est très puissant, mais également très dangereux. Si on donne à un agent le droit de faire n’importe quoi, il fera potentiellement n’importe quoi : supprimer un fichier, envoyer un document au mauvais destinataire ou modifier un système de manière inattendue.

La difficulté est donc de mettre en place des garde-fous suffisamment solides. On ne peut pas demander à des humains de valider chaque action si plusieurs dizaines d’agents travaillent simultanément. Mais on ne peut pas non plus leur donner un accès illimité.

Comment peut-on sécuriser ces agents autonomes ?

Une première stratégie consiste à isoler l’agent dans un environnement fermé, par exemple un conteneur. Il peut y faire ce qu’il veut à l’intérieur de cet espace, mais il ne dispose pas automatiquement d’un accès à l’ensemble du système.

Une autre approche consiste à utiliser des langages et des environnements qui imposent des contraintes fortes. L’idée est de générer du code, mais de ne pas l’exécuter directement. Le code est d’abord transmis à un outil qui va le compiler et vérifier qu’il respecte un ensemble de règles.

Dans ce type de modèle, le code ne peut rien faire par défaut. Il ne peut pas produire d’effet de bord, accéder à n’importe quelle ressource ou déclencher une action sans autorisation explicite. Les composants qui disposent de droits particuliers sont écrits et sécurisés séparément.

C’est une évolution intéressante pour les développeurs, car elle pourrait les amener à se concentrer davantage sur la conception de composants fiables, contrôlés et spécialisés. On retrouverait une logique proche de la “sécurité intégrée au code” : les contraintes ne sont pas ajoutées à la fin, elles sont prises en compte dès la conception.

Est-ce que tu refuses d’utiliser l’IA dans certains domaines pour des raisons éthiques ?

Je ne m’interdis pas vraiment un domaine ou une activité en particulier. Ce qui me gêne, ce n’est pas l’outil en lui-même, mais le fait de perdre la main.

On peut très vite intégrer l’IA dans un processus sans savoir exactement ce que l’on veut, ni comment elle fonctionne. Dans ce cas, on risque de se retrouver entraîné dans une direction que l’on n’a pas vraiment choisie.

Il m’arrive d’ailleurs de me demander quel sera l’avenir de certains métiers et de certaines compétences. Je ne suis pas particulièrement inquiet pour ma carrière, mais j’ai parfois besoin de réfléchir à la manière de continuer à travailler sur des sujets qui m’intéressent et dans lesquels je peux encore apporter quelque chose.

L’arrivée de l’IA modifie-t-elle la place des profils juniors dans les équipes ?

Dans mon environnement, nous avons recruté plusieurs profils juniors au cours des deux dernières années. Je n’ai pas constaté de disparition complète de ces recrutements, même si le marché est clairement plus compliqué.

Je pense toutefois que nous allons payer le manque de juniors. Une personne en début de carrière n’est pas seulement là pour exécuter des tâches simples. Elle apprend aussi en observant, en expérimentant et en faisant des erreurs.

Or l’IA fournit souvent des solutions qui fonctionnent en apparence, mais qui ne couvrent pas tous les cas. Si l’on ne prend pas le temps de comprendre pourquoi une solution fonctionne, quelles sont ses limites et quelles erreurs elle peut produire, on perd une partie essentielle de l’apprentissage.

L’IA peut absorber certaines tâches sans grande valeur, mais ces tâches avaient parfois une vraie utilité pédagogique. Elles permettaient d’apprendre progressivement le métier, de développer son jugement et de comprendre les problèmes.

Quel est le principal risque pour les personnes qui débutent dans le métier ?

Le risque est de devenir un simple exécutant. Si l’on commence sa carrière avec un outil qui prémâche une grande partie du travail, on peut perdre du temps d’apprentissage sans s’en rendre compte.

On apprend en faisant des erreurs, en anticipant les problèmes et en détectant ce qui ne fonctionne pas. Une solution générée automatiquement peut sembler juste parce qu’elle produit un résultat, mais cela ne signifie pas qu’elle est complète, robuste ou bien conçue.

Je suis assez pessimiste sur ce point. Les personnes qui n’auront pas été habituées à réfléchir aux problèmes, à analyser leurs erreurs et à comprendre les conséquences de leurs choix risquent de se retrouver en difficulté lorsque les limites des outils apparaîtront.

Quelle est, selon toi, la vraie valeur ajoutée d’un développeur ou d’une développeuse aujourd’hui ?

L’expertise reste essentielle, qu’elle soit technique ou liée à un domaine métier. Les modèles de langage reproduisent ce qui existe déjà. Ils disposent d’une connaissance considérable, mais ils ne créent pas à partir de rien. Il faut donc toujours des personnes capables de comprendre un sujet en profondeur, d’anticiper les besoins et de déterminer quelle solution est réellement pertinente.

La capacité à avoir une vision globale devient également très importante. Les profils capables de comprendre l’ensemble d’un système, le produit, le front-end, le back-end, les interactions et les contraintes métier, peuvent mieux identifier les endroits où il faut agir.

Cette vision permet ensuite d’utiliser l’IA de manière plus efficace : pour poser de meilleures questions, challenger une proposition, construire un plan d’implémentation ou vérifier qu’une solution répond bien au problème initial.

Le simple fait de savoir produire du code ou de rédiger des prompts devient moins différenciant. Ce qui compte davantage, c’est de savoir quoi demander, pourquoi le demander et comment évaluer le résultat.

Le software craft a-t-il encore une place dans ce nouvel environnement ?

Il se perd, c’est évident. Une partie du développement logiciel est de plus en plus orientée vers la vitesse de production et la quantité de code générée.

Pourtant, je continue à prendre du plaisir lorsque je peux concevoir proprement un composant ou résoudre un problème nouveau. L’IA peut m’aider à démarrer, à produire une première version ou à décliner une solution. Mais je veux pouvoir reprendre la main et améliorer ce qui a été généré.

Le problème apparaît lorsque l’on reste en permanence en réaction à l’IA : il faut relire ses propositions, corriger les erreurs, examiner les pull requests et comprendre des centaines de fichiers modifiés. Avec du code généré en grande quantité, les revues deviennent particulièrement épuisantes.

J’ai déjà vu des équipes en tension à cause de cela : des revues qui peuvent durer des heures voire une semaine car le code généré a été fait totalement à l’arrache et de façon rapide sans qualité pensée en amont. 

Le craft peut donc rester une source de plaisir, mais il faut réussir à préserver les espaces dans lesquels on peut encore réfléchir et construire avec attention.

N’y a-t-il pas une contradiction entre la recherche de contrôle et un modèle économique fondé sur la consommation de tokens ?

Il y a effectivement une tension. Plus on contrôle précisément ce que l’on demande, plus on limite parfois les générations inutiles et la consommation de tokens. Ce n’est pas forcément aligné avec les intérêts des vendeurs de modèles.

Je ne suis pas complotiste, mais il faut rester lucide. Si l’on demande plusieurs fois à une IA de faire la même chose, sans avoir clarifié le problème initial, on peut consommer beaucoup de ressources sans produire davantage de valeur.

À l’inverse, lorsque l’on sait précisément ce que l’on veut, que l’on connaît le domaine et que l’on avance par petites étapes, ces outils deviennent très efficaces. Ils sont particulièrement bons pour reproduire, décliner ou accélérer quelque chose qui a déjà été pensé.

La première version peut être produite très vite. Ensuite, il faut reprendre le travail manuellement pour obtenir quelque chose de propre et de durable.

Comment imagines-tu les prochaines années et l’évolution de ton propre métier ?

Je me projette plutôt vers les applications agentiques : des applications qui embarquent des agents capables de s’adapter et de produire elles-mêmes une partie de leur code.

Cela peut sembler futuriste, mais cette évolution pose surtout une question de contrôle. Si une application est capable de se modifier elle-même et d’agir sur son environnement, il faut lui donner des droits extrêmement précis. 

Je pense donc que les développeurs pourront se spécialiser dans la conception de composants très ciblés, avec des garanties fortes. Il faudra probablement davantage s’appuyer sur des langages contraints et sur des méthodes permettant de démontrer qu’un programme respecte bien certaines propriétés.

Les preuves formelles, par exemple, permettent de vérifier mathématiquement qu’un programme est correct dans un périmètre donné. Ce type d’approche pourrait prendre de l’importance dans un monde où des agents génèrent et exécutent du code de manière autonome.

Quel est le principal danger des outils actuels, au-delà des erreurs techniques ?

Le risque est de perdre l’orientation initiale du projet.

Lorsque l’on sollicite trop tôt une IA, elle peut proposer une solution à laquelle on n’aurait pas pensé. Cette solution peut être intéressante, mais elle n’est pas nécessairement la meilleure. On peut alors commencer à suivre la direction proposée sans avoir pris le temps de réfléchir au problème de départ.

Les outils sont extrêmement puissants et leur culture générale dépasse largement celle d’un individu. Mais cette puissance peut aussi nous faire abandonner trop rapidement notre propre raisonnement.

On se retrouve dans une logique de réaction : l’outil propose, on répond ; il génère une architecture, on la suit ; il produit une grande quantité de code, puis on essaie de comprendre ce qui a été fait.

J’ai récemment vu un projet démarré en quelques dizaines de minutes grâce à l’IA. Pourtant, la revue et la reprise du code m’ont demandé environ une semaine.

Il fallait comprendre l’organisation du projet, identifier les problèmes et corriger une quantité importante de travail inutilement complexe.

Le résultat pouvait fonctionner, mais cela ne signifie pas que le travail était terminé. C’est là toute l’ambivalence actuelle de l’IA : elle peut faire gagner énormément de temps au démarrage, tout en en faisant perdre beaucoup au moment de vérifier, de maintenir et de sécuriser ce qu’elle a produit.

À propos d’Olivier Nouguier

Senior Software Engineer, speaker et passionné par la programmation fonctionnelle, Olivier Nouguier évolue au cœur des architectures distribuées (Big Data, Scala, ZIO, Kafka, Akka Streams). Spécialiste des systèmes complexes et du streaming de données, il s'intéresse de près à l'impact de l'IA sur les métiers du développement, le code et l'ingénierie logicielle.

Ses projets & contributions Open Source

• Écosystème Scala & ZIO : Contributeur actif sur de nombreux projets Open Source, notamment sur des librairies d'interface et d'architecture (Laminar Form Derivation, ZIO-Pravega, ZIO-Laminar-Tapir).
• Publications & Technique : Auteur et créateur de contenus techniques (notamment sur des plateformes comme Rock the JVM).

Interventions & Communauté

• Conférences & Tech Talks : Speaker régulier dans l'écosystème tech et engagé dans la vie des communautés de développeurs (implication historique au sein de tech hubs et de JUGs comme le JUG Montpellier).
• Veille & Réflexion IA : Intervenant et mentor sur les pratiques de dev modernes à l'ère des LLM et de l'assistance au code.

Où le retrouver ?

• Site / Projets : cheleb.github.io (Projets & documentations)
• GitHub : github.com/cheleb
• LinkedIn : linkedin.com/in/olivier-nouguier
• Bluesky : @onouguier.bsky.social