Je ne suis pas un bon développeur. Et c'est précisément pour ça que l'IA a changé ma façon de créer

Note sur la rédaction de cet article

Oui, cet article a été rédigé avec l’aide d’une IA. En revanche, les idées, opinions et expériences qui y sont exprimées sont entièrement les miennes. Le texte est issu de longues discussions préalables au cours desquelles j’ai développé ma pensée, répondu à des questions et précisé mon point de vue. L’IA a principalement servi à organiser et formuler cette matière sous la forme d’un article. J’ai ensuite relu, corrigé et validé l’intégralité du texte avant publication.

Je vais commencer par quelque chose qui peut paraître étrange venant de quelqu’un qui développe des applications depuis plusieurs années : je ne me considère pas comme un très bon développeur.

Ce n’est pas de la fausse modestie et je ne dis pas ça pour qu’on vienne m’expliquer que j’ai le syndrome de l’imposteur et qu’en réalité je suis formidable.

J’ai réellement des lacunes techniques. Je ne suis pas particulièrement bon en algorithmique, je n’ai jamais eu une grande facilité avec l’abstraction informatique ou les mathématiques, et je ne suis pas le genre de personne qui peut ouvrir un éditeur et commencer à construire une architecture complexe de tête.

Pourtant, je développe.

Et même plutôt beaucoup.

C’est justement pour ça que mon expérience avec les LLM me paraît intéressante.

Je développais déjà avant ChatGPT

J’ai commencé avec un bootcamp en 2020-2021 autour de HTML, CSS, JavaScript, PHP et Symfony.

Ensuite, comme beaucoup de développeurs autodidactes ou issus de formations courtes, j’ai continué à apprendre en faisant.

Pendant un stage de six mois chez Plastic Omnium, j’étais le seul développeur. J’avais été recruté par l’IT du site, qui était surtout administrateur système et avait besoin de petites solutions web internes.

J’en ai développé plusieurs.

Une première application très simple permettait de comparer des codes-barres. Si les deux correspondaient, l’écran affichait un énorme message vert. Sinon, un énorme message rouge. L’objectif était simplement d’éviter certaines erreurs d’expédition de pièces.

J’ai aussi développé une application Symfony de gestion des ouvriers de l'usine (création et attribution à des postes).

Enfin, j’ai réalisé une interface connectée à SQL Server qui affichait en direct la production de plusieurs îlots sur un écran divisé en quatre.

Tout cela existait avant la démocratisation des LLM.

Donc non, l’IA ne m’a pas soudainement permis de passer de zéro connaissance à la création d’applications.

Mais ma manière de développer à cette époque était déjà révélatrice.

Je regardais des tutoriels sur Udemy et YouTube. Je cherchais sur Google. Quand j’étais bloqué, j’allais sur Stack Overflow. Je trouvais quelqu’un qui avait rencontré un problème similaire, j’essayais d’adapter la réponse à mon cas et j’avançais.

Je pouvais produire quelque chose de fonctionnel sans forcément comprendre profondément tout ce que j’utilisais.

Avec du recul, Internet avait déjà commencé à externaliser une partie de mes compétences.

Je n’avais pas toutes les connaissances dans ma tête. Je savais surtout où les chercher et comment les assembler suffisamment bien pour arriver au résultat que je voulais.

Puis les LLM sont arrivés.

Les LLM n’ont pas changé ma nature, ils ont supprimé la friction

La grande différence avec ChatGPT, Claude, Gemini, DeepSeek et les autres n’est pas simplement qu’ils écrivent du code plus vite que moi.

C’est que presque toute la friction qui existait entre une idée et sa réalisation a disparu.

Avant, une fonctionnalité pouvait me demander plusieurs heures simplement parce que j’allais rencontrer un problème technique, chercher une solution, lire plusieurs réponses, tester quelque chose, constater que ça ne fonctionnait pas, recommencer.

Aujourd’hui, quand je bloque, je peux expliquer précisément le problème à un modèle.

S’il n’arrive pas à le résoudre, j’en teste un autre.

Si le contexte devient trop complexe, je peux exporter le code, donner davantage d’informations et faire analyser le problème par plusieurs modèles.

Dans l’immense majorité des cas, je finis par être débloqué très rapidement.

Le résultat est assez paradoxal : je suis devenu beaucoup plus productif sans être devenu proportionnellement meilleur en programmation.

Et je dirais même qu’il y a un effet inverse.

Je cherche moins à comprendre qu’avant.

Avant, être bloqué m’obligeait parfois à comprendre ce qui se passait. Maintenant, le blocage disparaît souvent avant que cette compréhension devienne nécessaire.

C’est probablement l’un des aspects les moins confortables de ma manière de travailler aujourd’hui. Je produis davantage, mais j’exerce moins certaines compétences.

En réalité, je n’ai jamais vraiment voulu être programmeur

Pendant longtemps, j’ai assimilé le fait de créer un logiciel au fait d’être développeur.

Aujourd’hui, je fais beaucoup plus clairement la distinction.

Ce qui m’intéresse vraiment, c’est le produit.

Quand j’imagine une fonctionnalité pour LingRise, mon premier réflexe n’est presque jamais de me demander quelle structure de données utiliser, quel design pattern choisir ou comment organiser les composants.

Je pense d’abord à ce que la fonctionnalité doit apporter.

Comment l’utilisateur va l’utiliser.

Pourquoi elle devrait exister.

Ce qui serait agréable, pratique ou frustrant.

Le "comment" technique est devenu secondaire.

Je sais que cette position fera probablement bondir certains développeurs, mais pour la majorité des projets que j’ai envie de créer, je me fiche assez largement de savoir si une application est construite avec Symfony, Laravel, React ou autre chose.

Même chose pour une application mobile entre Flutter, React Native, Kotlin ou Swift.

Je ne dis pas qu’il n’existe aucune différence. Évidemment qu’il y en a.

Je dis simplement que dans mon contexte, pour la grande majorité des produits classiques que je pourrais vouloir construire, ces différences ont beaucoup moins d’importance que la qualité du produit lui-même.

Je ne travaille pas sur un système bancaire critique, sur un dispositif médical ou sur une infrastructure où quelques millisecondes, une propriété mathématique particulière ou certaines garanties techniques peuvent devenir fondamentales.

Je construis des produits destinés à des utilisateurs.

Ma question principale est donc devenue : qu’est-ce qu’on devrait construire ?

Pas : est-ce que je sais techniquement le construire ?

Et l’IA a énormément accéléré cette transition.

LingRise n’aurait probablement jamais existé avant

C’est peut-être le meilleur moyen de mesurer l’impact réel de l’IA sur moi.

Sans les LLM, je n’aurais probablement jamais lancé LingRise.

Pas parce que le projet aurait été impossible.

J’aurais pu apprendre. J’aurais pu passer des centaines (miliers ?) d’heures supplémentaires à chercher, expérimenter et développer.

Mais c’est justement le problème.

Je ne l’aurais probablement pas fait.

Le coût aurait été trop élevé par rapport à ma motivation pour la programmation elle-même.

L’IA a changé les idées que je considère comme réalisables.

Avant, on pouvait avoir une idée et immédiatement penser aux semaines ou aux mois de développement nécessaires.

Aujourd’hui, je peux beaucoup plus facilement me dire : essayons.

Et je pense que cette évolution va avoir des conséquences beaucoup plus importantes que le simple gain de productivité des développeurs existants.

Si construire devient plus facile, avoir la bonne idée devient plus important

On répète souvent qu’une idée ne vaut rien sans exécution.

Je comprends ce que cette phrase veut dire, mais je pense que l’IA change progressivement l’équation.

Quand l’exécution coûte extrêmement cher, énormément de bonnes idées ne voient jamais le jour.

Si son coût baisse, davantage de personnes peuvent tester leurs idées.

Pour moi, c’est une bonne nouvelle pour l'humanité.

Il existe probablement énormément de gens qui ont de très bonnes intuitions, comprennent parfaitement un problème ou imaginent des produits intéressants, mais qui n’auraient jamais passé deux ans à apprendre le développement pour les construire.

L’IA leur donne une chance.

Évidemment, à titre personnel, c’est un peu moins pratique parce que cela signifie aussi beaucoup plus de concurrence.

Et je ne suis pas certain que LingRise échappera à cette nouvelle réalité. J’aime beaucoup ce que je construis et je pense que le produit a un gros potentiel, mais je suis parfaitement conscient qu’il pourrait aussi rejoindre un jour la gigantesque pile des SaaS que quelqu’un a construits et que presque personne n’utilise.

Parce que si tout le monde peut construire, le problème se déplace : il faut construire quelque chose que les gens veulent réellement.

Et à ce moment-là, le produit, le design, le marketing, la compréhension des utilisateurs, la stratégie et la créativité prennent encore plus de valeur.

C’est là que je me sens beaucoup plus à ma place.

Mon syndrome de l’imposteur ne concerne pas tout

Je doute énormément de moi quand il s’agit de développement. Sur les abstractions informatiques ou les compétences techniques pures, je me considère franchement médiocre.

En revanche, je n’ai pas du tout le même rapport à l'imagination.

C’est probablement la qualité dans laquelle j’ai le plus confiance.

Un exemple assez idiot me revient souvent. Au bac de français, je n’avais pratiquement rien révisé, mais l’une des épreuves demandait d'imaginer et rédiger la suite d’un texte. J’avais eu 18/20.

Ça peut sembler anecdotique, mais c’est assez représentatif de ce qui m’a toujours attiré.

Imaginer.

Créer quelque chose qui n’existe pas encore.

Trouver une direction.

Et mon rêve ultime n’a d’ailleurs jamais été de devenir un développeur exceptionnel.

J’aimerais un jour écrire une œuvre mémorable, quelque chose qui puisse me marquer autant qu’une œuvre comme l'Attaque des Titans m’a marqué.

Et là, paradoxalement, je ne voudrais pas que l’IA l’écrive à ma place.

Je pourrais l’utiliser pour relire un passage ou me proposer une meilleure formulation, mais l’œuvre, les personnages, l’histoire et les idées, je voudrais qu’ils viennent de moi.

C’est une frontière importante dans mon rapport à l’IA.

Je n’ai aucun attachement particulier au fait d’écrire moi-même une fonction PHP ou Java si une machine peut le faire mieux et plus vite.

En revanche, je tiens énormément à rester l’auteur de ce que je considère comme réellement créatif et personnel.

Le code qui fonctionne n’est pas forcément du bon logiciel

Évidemment, déléguer autant à l’IA pose un problème.

Un LLM est extrêmement doué pour produire une solution qui fonctionne maintenant.

Ça ne veut pas dire qu’il produit spontanément une solution dont vous serez satisfait dans deux ans.

J’en ai fait l’expérience sur LingRise.

Sur une fonctionnalité liée à l’audio, l’IA avait choisi une solution techniquement fonctionnelle mais mauvaise d’un point de vue architectural. Elle privilégiait la voie la plus directe au lieu de réfléchir à la réutilisation et à la cohérence du système à long terme.

Le code fonctionnait. Mais la décision était vraiment mauvaise.

C’est probablement l’une des leçons les plus importantes que j’ai apprises en travaillant avec des LLM.

Ils ont tendance à chercher un chemin rapide vers une réponse satisfaisante.

Et quand on développe un vrai produit, ce n’est pas toujours ce qu’on veut.

Le bon logiciel n’est pas uniquement du code qui passe les tests aujourd’hui.

C’est aussi un système qu’on pourra comprendre, modifier et maintenir demain.

Après cette erreur, j’ai changé ma manière de travailler.

J’utilise notamment beaucoup BMAD (Breakthrough Method for Agile AI-Driven Development), pour structurer davantage le travail des agents, leur donner du contexte et faire intervenir plusieurs étapes de contrôle.

J’essaie aussi d’être beaucoup plus attentif aux choix qui peuvent avoir des conséquences à long terme.

C’est là que je pense que le rôle du développeur évolue réellement.

Comprendre les conséquences devient plus important qu’écrire vite

Si je devais compléter une phrase sur l’évolution du métier, je dirais ceci :

Avec l’IA, le développeur n’est plus principalement quelqu’un qui sait coder rapidement, mais quelqu’un qui comprend les implications de chaque décision et qui sait orienter les LLM pour ne pas créer de dette technique et perdre du temps.

C’est très différent.

Produire dix fois plus de code n’a aucune valeur si on produit dix fois plus vite une architecture catastrophique.

Quand des agents deviennent capables d’implémenter une quantité énorme de travail, le goulot d’étranglement se déplace.

Il faut être capable de dire ce qu’on veut.

De donner les bonnes contraintes.

De détecter une décision douteuse.

De savoir quand demander une deuxième analyse.

De comprendre qu’une solution localement élégante peut créer un problème global.

Et c’est précisément là que mes propres limites deviennent dangereuses.

Je peux superviser beaucoup de choses.

Mais je sais aussi qu’il existe des situations dans lesquelles je ne suis pas suffisamment compétent pour juger correctement ce que l’IA me propose.

Je préfère l’admettre plutôt que prétendre que quelques prompts me transforment soudainement en ingénieur senior.

Je ne ferais pas confiance à l’IA pour tout

Je n’ai aucune envie de tomber dans le discours selon lequel il suffit aujourd’hui de lancer quelques agents pour remplacer n’importe quelle équipe d’ingénieurs.

Je fais confiance à l’IA proportionnellement au coût potentiel de son erreur.

Si elle choisit une mauvaise abstraction pour une petite fonctionnalité et que je perds trois heures, ce n’est pas dramatique.

Si elle introduit une vulnérabilité dans le paiement, l’authentification ou la gestion des données utilisateurs, le problème n’est plus du tout le même.

Si LingRise fonctionne suffisamment bien et commence à avoir une vraie utilisation, je compte faire relire les parties fondamentales par quelqu’un de réellement compétent, notamment ce qui touche aux paiements, à la sécurité et aux comptes utilisateurs.

Pour moi, la règle est assez simple.

Plus une décision est facile à annuler et peu dangereuse, plus je peux déléguer.

Plus les conséquences potentielles deviennent importantes, plus j’ai besoin de compréhension et de validation humaines.

Ce principe explique aussi pourquoi je ne généralise pas mon expérience à tous les domaines.

Construire une petite application SaaS et construire un système bancaire ou médical ne demandent évidemment pas le même niveau de prudence.

Je ne pense pas non plus que le diplôme règle magiquement le problème

L’inverse serait cependant tout aussi simpliste.

Dire que des humains compétents sont nécessaires ne signifie pas que mettre dix ingénieurs diplômés dans une pièce garantit automatiquement un excellent logiciel.

On voit régulièrement des systèmes construits par de grosses organisations rencontrer des problèmes majeurs.

La compétence technique compte énormément, mais elle n’est qu’une partie de l’équation.

Il faut aussi du sérieux, de la volonté, des moyens, du temps, une bonne organisation, une maintenance correcte et des gens suffisamment motivés et bien payés pour faire correctement leur travail.

Le fait que des experts puissent commettre des erreurs n’est donc pas une preuve que l’expertise ne sert plus à rien.

C’est simplement une preuve que la construction de logiciels complexes est difficile.

IA ou pas.

Je ne suis pas sûr que les LLM soient "plus intelligents" que moi

Il m’arrive maintenant de laisser les modèles réfléchir à énormément de problèmes à ma place.

Pas forcément parce que je les considère comme intelligents au sens humain du terme.

On pourrait passer des heures à discuter de ce que signifie réellement l’intelligence.

Ce qui m’intéresse davantage, c’est le résultat pratique.

Ils disposent d’une masse de connaissances à laquelle je ne peux pas me comparer et d’une vitesse d’exécution largement supérieure à la mienne.

Pour énormément de problèmes, je n’ai donc simplement plus intérêt à partir seul pendant une heure dans une réflexion qu’un modèle peut explorer en quelques secondes.

Mais ça crée un autre risque.

À force de déléguer la réflexion, on devient potentiellement moins capable de réfléchir soi-même.

Je le vois chez moi.

C’est un compromis que j’accepte aujourd’hui parce que mon objectif principal est de construire.

Quelqu’un dont l’objectif est de devenir un excellent ingénieur devrait probablement avoir une approche très différente.

Si j’avais 20 ans aujourd’hui, je ne choisirais probablement pas le développement

C’est peut-être ma conclusion la plus personnelle.

Si j’avais aujourd’hui 20 ans et que je devais choisir une carrière, je ne pense pas que je deviendrais développeur.

Pas parce que je pense que le métier va disparaître.

Je n’en sais rien, et je me méfie énormément des prédictions trop certaines sur ce sujet.

Je ferais simplement un calcul par rapport à mon propre profil.

Je ne suis pas passionné par le code lui-même.

Je ne suis pas excellent en mathématiques ou en abstraction.

Je ne prends pas particulièrement de plaisir à comprendre le fonctionnement interne d'un système pendant des heures simplement parce que le problème est intéressant.

Ce qui m’attire, ce sont les produits et les idées.

Dans un marché où énormément de personnes apprennent à développer, où la concurrence est mondiale et où les entreprises peuvent probablement produire davantage avec moins de développeurs grâce à l’IA, je ne vois pas pourquoi je choisirais volontairement de me battre sur l’un de mes points faibles.

Je m’orienterais beaucoup plus naturellement vers le produit ou vers un autre domaine dans lequel ma capacité à imaginer et concevoir quelque chose serait davantage centrale.

En revanche, je ne donnerais absolument pas ce conseil à tout le monde.

Si tu as 18 ou 20 ans, que tu es excellent en abstraction, que tu adores les mathématiques, les systèmes, la programmation, la sécurité ou la compréhension profonde des ordinateurs, fonce.

L’IA pourrait même te rendre incroyablement puissant.

Si tu as de très bonnes idées et que tu veux apprendre suffisamment de technique pour les matérialiser, fonce également. La barrière n’a probablement jamais été aussi basse.

Mais si tu es simplement quelqu’un de lambda à qui on a vendu le développement comme un eldorado facile, je serais beaucoup plus prudent.

Tu risques de te retrouver en concurrence avec des millions de personnes qui ont eu exactement la même idée que toi, auxquelles il faut maintenant ajouter des machines capables de produire une quantité de code inimaginable il y a encore quelques années.

Apprendre quelques frameworks ne suffit probablement plus à constituer un avantage durable.

Peut-être que je suis exactement le type de créateur que l’IA va multiplier

Je trouve finalement assez difficile de dire si je suis encore vraiment un développeur.

Je construis du logiciel.

Je prends des décisions produit.

Je définis des fonctionnalités.

Je donne des instructions à des agents.

Je teste manuellement.

Je demande aux agents de corriger lorsque je trouve des défauts.

Je choisis parfois entre plusieurs solutions.

Je surveille les conséquences de certains choix.

Mais je n'écris plus de code moi-même.

Et je n’ai pas particulièrement envie que ça change.

Peut-être que dans quelques années, mon profil sera complètement banal.

Des personnes qui comprennent suffisamment la technique pour dialoguer avec les machines, mais dont la vraie valeur se trouve ailleurs.

Dans leur connaissance d’un métier.

Dans leur compréhension d’un utilisateur.

Dans leur goût.

Dans leur capacité à vendre.

Dans leur créativité.

Dans leur imagination.

Dans leur faculté à identifier un problème intéressant avant les autres.

Je trouve cette perspective à la fois enthousiasmante et inquiétante.

Enthousiasmante parce que davantage de personnes vont pouvoir créer.

Inquiétante parce que lorsque tout le monde peut construire, construire ne suffit plus.

Et peut-être qu’au fond, c’est ça que l’IA change vraiment pour moi.

Elle ne m’a pas appris à aimer programmer.

Elle ne m’a pas transformé en excellent ingénieur.

Elle a simplement réduit le coût technique de la création de logiciels au point où je peux aujourd’hui construire des choses que je n’aurais probablement jamais pris le temps de construire auparavant.

Pendant des décennies, transformer une idée en logiciel demandait nécessairement de maîtriser une quantité importante de connaissances techniques et d’y consacrer énormément de temps. Pour quelqu’un comme moi, qui aime davantage imaginer des produits que programmer, cette contrainte limitait naturellement ce que je pouvais réaliser.

Les LLM ne suppriment pas cette contrainte complètement. Ils ne remplacent pas totalement la compréhension technique, le jugement ou la responsabilité.

Mais ils la réduisent suffisamment pour changer ce que je considère comme possible.

Et c’est probablement la conséquence la plus importante de l’IA dans ma propre vie : je peux consacrer davantage de mon temps à ce dans quoi je pense être bon.

Avoir des idées.

Imaginer des produits.

Créer.

Le reste, je peux de plus en plus souvent le déléguer à une intelligence artificielle.