50% des devs génèrent plus d’un quart de leur code avec de l’IA - SMALLTALK #6

Matthieu : Bonjour à toutes et à tous, bienvenue dans ce nouvel épisode. Aujourd'hui, on va parler d'IA et plus précisément de la façon dont les développeurs utilisent l'IA. On a un invité, Eric Burel. Salut Eric !

Eric : Salut tout le monde !

Matthieu : Tu es notre formateur Astro et Next.js chez Human Coders, mais tu as aussi une autre fonction : tu t'occupes de tous les "State of". J'ai cru comprendre qu'il y en avait beaucoup, tu vas nous les présenter. Petite anecdote, c'était super de se voir mercredi dernier au Montpellier Tech Hub et au Montpellier JS. Tu donnais une conférence sur la sécurité sur Next et moi je parlais d'art génératif, une passion qui me parle beaucoup. C'était une super soirée. Est-ce que tu peux déjà nous présenter un peu ce que sont les "State of" ?

Présentation de l'enquête State of AI

Eric : Les "State of", ce n'est pas une marque déposée, donc on ne fait pas tous les trucs qui s'appellent comme ça, car il y en a beaucoup. Mais on se défend pas mal, on en fait beaucoup. Si tu prends la liste de toutes les technologies pour faire un site web aujourd'hui, tu as une bonne probabilité qu'on soit dedans. Historiquement, on est partis du JavaScript. State of JS est l'enquête la plus connue. Ce n'est pas moi qui l'ai créée, c'est Sacha Greif, qui est aussi un développeur français expatrié au Japon. Il est à Kyoto aujourd'hui et travaille à plein temps sur ce projet. C'est un développeur open source de longue date dans l'écosystème JavaScript, à l'époque de Meteor, des débuts de React et de GraphQL. J'ai rejoint le projet progressivement.

State of JavaScript, c'est le gros projet. Rapidement, on se rend compte que le CSS a aussi beaucoup bougé ces dernières années avec énormément de nouvelles fonctionnalités, donc on a un State of CSS. Le HTML a aussi évolué, les navigateurs intègrent plein de fonctionnalités maintenant, surtout depuis la fin d'Internet Explorer. On peut commencer à faire du développement web sérieux en HTML. Derrière, on a les frameworks, donc on a le State of React. On a aussi des façons de structurer nos API avec le State of GraphQL.

Tout ça nous amène, une fois qu'on a couvert les technologies, à nous pencher sur des aspects d'innovation ou organisationnels. C'est là qu'on va parler du State of Web Dev AI. State of AI est un nom repris par plusieurs sociétés qui font leur revue de littérature là-dessus. Le State of Dev AI est en cours au moment où on enregistre. J'ai surtout contribué à créer l'application Next.js de questionnaire pour que ça fonctionne sur un grand volume d'enquêtes. On a quelques dizaines de milliers de réponses par an à gérer. On en a eu 4000 sur le State of AI pour une première édition. Pour le HTML, les gens étaient complètement surpris de l'évolution du langage et on était à plus de 30 000 réponses. Sacha Greif travaille à plein temps dessus, il décide des choix de sujets, travaille sur les questionnaires et va chercher les partenariats, comme avec Google pour l'intégration de l'IA dans les navigateurs par exemple.

Matthieu : Merci pour ça, c'est très utile, on les regarde tous avec grande attention. Est-ce qu'avant de regarder les stats, tu pourrais nous présenter l'ambition avec State of AI ? Quelles étaient les questions que vous vous posiez et qu'est-ce que ça parcourt un petit peu ?

Eric : Sur State of AI, on a toujours été chercher les phénomènes de mode et les tendances. C'est un format d'enquête ouverte. Méthodologiquement, ça s'oppose un peu aux enquêtes statistiques qui vont interroger 1000 personnes représentatives. L'enquête ouverte, c'est laisser n'importe qui répondre et viser le volume pour identifier de grosses tendances. On est un peu entre ce qui se passe sur Twitter, poussé par une poignée d'influenceurs, et l'enquête scientifique qui est très coûteuse et pas forcément faisable en temps réel. On essaie de capturer les tendances en laissant tout le monde répondre, en tout cas un nombre conséquent de personnes dans l'écosystème. L'IA est incontournable parce que tout le monde s'empare du sujet. Chacun essaie de pousser sa technologie. On a essayé de démêler ça et de mieux comprendre cet écosystème. On n'est pas experts des technologies sur lesquelles on pose des questions, même en JavaScript ou React, car suivre l'actualité est très dur. Ça nous permet, même à nous en tant que créateurs des enquêtes, d'essayer de comprendre ce qui se passe. Pour l'IA, c'était assez évident qu'il y avait un besoin de comprendre ce qui se passe dans ce monde. On est sur de l'IA pour le développement web, on a une population de développeurs web essentiellement sur cette enquête.

Démographie des répondants

Matthieu : On peut rentrer dans le vif du sujet. On va partager ton écran, mais ne vous inquiétez pas si vous écoutez, on va faire attention à ce que le podcast soit agréable à écouter.

Eric : On a la super intro de Sacha pour comprendre ces questions : ce que les développeurs vont penser de l'intelligence artificielle, quels outils ils utilisent, quels sont leurs points de difficulté aujourd'hui parce que c'est quand même très neuf. Pour la démographie, comme c'est ouvert, on a besoin de savoir qui répond pour savoir s'il y a des biais. On a 19 % de répondants aux USA, et ensuite une majorité en Allemagne, en France, au Royaume-Uni et en Pologne pour les cinq premiers. C'est quand même Europe de l'Ouest et USA. On a quand même 40 pays représentés avec au moins une dizaine de répondants par pays. Au niveau de l'expérience, on a des développeurs plutôt de niveau intermédiaire, 5 à 9 ans d'expérience. Au niveau des tailles d'entreprise, on a un peu de tout : 19 % d'entreprises de plus de 1000 employés, et beaucoup de petites entreprises, TPE ou freelances (9 %). C'est assez hétérogène au niveau des revenus et de la formation.

Les modèles de langage (LLM)

Matthieu : On peut passer aux modèles, c'est la grosse question.

Eric : Clairement, pas trop de surprise, on a une majorité de Chat GPT. Le système de visualisation est assez élaboré, c'est Sacha qui l'a créé. On a les répondants qui ont utilisé la technologie, ceux qui voudraient l'utiliser, ceux qui en ont entendu parler et ceux qui ne l'ont pas utilisée. Sur Chat GPT, il n'y a à peu près personne qui n'en a pas entendu parler. On est à 97,2 % qui l'ont utilisé ou en ont entendu parler, et 91,2 % des répondants qui l'ont utilisé. C'est vraiment la base des LLM, de l'IA générative.

Matthieu : Là, on parle d'un usage hors IDE, c'est ça ?

Eric : Globalement, "j'ai utilisé Chat GPT". Ce n'est pas ciblé, c'est pour savoir si les développeurs sont plutôt team OpenAI, team Anthropic ou autre chose. Chat GPT est sur-représenté. On a Claude qui vient en second, ça correspond aussi à ce qu'on voit dans l'industrie. Après, on a Microsoft Copilot, mais il y a toujours le risque de confusion avec GitHub Copilot. Les noms ont été pris de façon très proche. Microsoft Copilot, la plateforme pour entreprise, je la vois beaucoup en entreprise autour de moi. On a Gemini qui suit de près. Les trois, Copilot, Gemini et Claude, sont à quasi-égalité à un peu plus de 50 %.

DeepSeek apparaît assez tôt, je ne pensais pas qu'il y avait 44 % d'usage. Ça dépend peut-être du moment où vous avez posé la question.

Eric : Je pense que ça a dû être publié juste après les grosses annonces qu'ils ont faites. La grosse annonce de DeepSeek est qu'ils ont réussi à passer beaucoup de bancs d'essai avec brio, mais avec des modèles plus petits et une meilleure architecture. C'est super important dans le monde des LLM parce qu'on parle de très grosses IA en taille, des trucs qui pèsent des gigas. Tout le monde cherche des trucs aussi puissants mais plus petits, car moins chers à opérer, moins chers à entraîner et qui consomment moins d'énergie. DeepSeek a des versions open source aussi, alors que sur Claude ou OpenAI, on est plutôt sur du privé pur et dur. On voit les petits Français de Mistral à un peu moins de 18 %.

Matthieu : C'est étonnant, je ne sais pas à quel point il y a un rayonnement international, je ne pensais pas les voir peut-être aussi haut.

Eric : Il y a un rayonnement international, mais au moment où on a fait l'enquête, Codestral version 2 n'était pas encore annoncé. Mistral est plutôt un généraliste qui n'avait pas forcément un ancrage dans la génération de code. On utilise quand même des versions un peu spécialisées de LLM en général pour le développement. Mistral joue plus sur le côté généraliste et le côté souverain européen. C'est une performance qui n'est pas si mal par rapport au type d'outil que c'est.

Matthieu : C'est un choix multiple ? En tant que développeur, j'aurais pu cocher plusieurs de ces modèles. J'utilise un peu Chat GPT pour de l'analyse et plutôt Claude pour la génération de code.

Eric : Complètement, tu peux choisir plusieurs outils. Ce sont des outils que tu as utilisés, ça ne veut pas forcément dire que tu vas continuer à les utiliser. En vert, on a les gens qui ont dit "j'ai utilisé, c'était génial". On a ceux qui l'ont utilisé et n'ont rien dit de plus, et ceux qui ont utilisé mais ont dit que ce n'était pas terrible. Sur Chat GPT, tu as 91 % des gens qui l'ont utilisé, 52 % qui disent que c'était positif et 34 % qui ne disent rien. Tu n'es pas loin des 90 % qui étaient contents. Tu n'as que 5 % de gens qui ont trouvé ça négatif. On collecte aussi cette info pour faire la différence entre "je l'ai utilisé et je vais probablement continuer" versus "je vais arrêter". On voit par exemple que les gens sont un peu plus insatisfaits de Copilot que de Chat GPT.

Eric : C'est le truc qu'on te met en entreprise, donc je ne sais pas si ça joue avec le fait d'être peut-être un peu forcé. Je vois beaucoup de gens forcés d'utiliser Microsoft Copilot parce qu'ils sont en environnement Microsoft et qu'ils n'ont pas forcément le choix pour plein de raisons légitimes d'un point de vue entreprise (contractuel, confidentialité, cohérence avec les autres outils bureautiques). Plus tu as un outil utilisé, plus il risque d'avoir des opinions négatives. Ça peut être un signe de maturité d'avoir beaucoup d'opinions négatives. On le voit beaucoup sur les frameworks, tu as le hype initial, puis quand on commence à être mature, on a une opinion très modérée.

Les difficultés rencontrées (Hallucinations et Contexte)

Eric : Ensuite, on a pour chaque section des "pain points", des points de difficulté. Spoiler alert : ce sont un peu les mêmes sur chaque section. Les hallucinations arrivent en tête. Il t'importe telle librairie ou fait telle chose en React et il t'invente les librairies qui permettent de faire le truc que tu as demandé parce que la librairie n'existe pas encore. Tu as quand même 46 % des répondants qui disent que c'est leur pain point majoritaire. Ensuite, la taille du contexte : je ne peux pas mettre tout mon code dans Chat GPT pour qu'il comprenne toute mon application et tout le code que j'ai écrit dans toute ma vie. J'ai 200 000 tokens, c'est-à-dire environ 200 000 mots ou caractères, je ne peux pas en mettre 20 millions. C'est ce qui revient avec 16 % des pain points. Les hallucinations sont clairement majoritaires aujourd'hui.

Matthieu : J'avais publié sur Human Coders News il n'y a pas longtemps un article où ils profitaient justement de l'hallucination des noms de paquets NPM pour de la sécurité. C'était assez flippant. Assez souvent, les LLM peuvent suggérer du code avec des noms de paquets qui n'existent pas, mais ce sont souvent les mêmes noms qui reviennent. Il y a des hackers qui font de vraies libs qui font ce que vous pensez, mais en plus en injectant du code malicieux. C'est très pervers.

Eric : L'inventivité des pirates est quand même très forte, ils se sont approprié ces technologies plus vite que les développeurs. Méfiez-vous des hallucinations, ça peut être dangereux. Côté contexte, j'ai l'impression que ça bouge. Il y a une progression sur le LLM de la taille des contextes et j'ai l'impression que les IDE genre Cursor facilitent ça parce qu'ils ont tout un process d'indexation et ils arrivent à s'abstraire un peu des limitations du contexte LLM. À la fois les LLM progressent et les IDE aussi. La plupart des IDE genre Cursor sont de plus en plus à l'aise à manipuler des codebases pas si mal.

Eric : Ils deviennent meilleurs. Moi, c'est tout ce que je range dans le terme architecture. Si tu prends le LLM tel quel, c'est un modèle qui prédit la suite. Tu lui donnes une entrée de code et il prédit la suite, c'est aussi bête que ça. Ce qui compte, c'est la façon dont tu vas l'utiliser en découpant ce code en morceaux qui font sens pour le faire rentrer dans ta fenêtre de contexte. Même si elle est large, tu as des modèles avec des fenêtres de contexte à 200 000 caractères, en général tu vas essayer d'éviter d'aller à la limite de contexte. Ce sont des maximums théoriques mais la qualité baisse beaucoup. Il vaut mieux avoir plusieurs prompts plus petits dans tous les cas. Il y a une progression là-dessus qui est assez impressionnante.

Les éditeurs spécialisés : L'ascension de Cursor

Eric : On passe côté éditeur. Le top 1 de l'utilisation, c'est Cursor avec 33 % des répondants sur 4000 qui l'ont utilisé. Si je trie par sentiment, on a 30 % des répondants qui ont un sentiment positif sur Cursor. Soit ils l'ont utilisé et ils sont contents, soit ils pensent l'utiliser, ils en ont entendu parler en bien. Le compétiteur qui revient tout de suite après, c'est Zed avec 15 % d'opinions positives, mais tout de suite beaucoup moins d'utilisation pratique (17 % des répondants). Après on a Windsurf et Void qui vont suivre. Void, ce sont surtout des gens qui en ont entendu parler.

Matthieu : Vous ne comptez pas Claude Code dans les IDE ?

Eric : Ça vient après, dans ce qu'on a mis dans "autre". Là ce sont les spécialisés parce qu'ils ont fait beaucoup de bruit en disant "on va faire un éditeur de texte qui est AI-first", c'est-à-dire qu'il est fait pour optimiser l'utilisation de l'IA. Je suis toujours très étonné de la com de Zed qui communique sur la vitesse. Encore leur dernier article où ils annoncent des nouveautés sur l'IA, leur titre même est centré sur la vitesse. Je n'arrive pas à savoir pourquoi ils font ça. En tout cas, je ne suis pas gêné par la vitesse de Cursor sur l'affichage, mes tabs s'affichent assez vite. Je suis étonné que leur principale com soit là-dessus. Il est deux fois moins utilisé que Cursor, mais c'est quand même un acteur plus récent.

Eric : Cursor, pour moi, c'est un VS Code-like. Tu restes sur une grosse appli Electron à la fin. VS Code, c'est de l'Electron, donc c'est du logiciel, c'est une appli web sous forme de logiciel. D'ailleurs, Atom à l'époque de GitHub était aussi sur cette techno et Microsoft a racheté GitHub, donc c'est cohérent de retrouver cette techno sur VS Code. Cursor est un VS Code-like, c'est même un fork à la base. Tu es sur un truc quand même lourd, réputé pour être lourd. C'est le cycle de vie des éditeurs de texte : il est nouveau, super léger, puis on met des fonctionnalités, il est lourd, puis il y en a un nouveau. C'est le même cycle avec Cursor et Zed. Zed a recodé un éditeur de texte de zéro qui est plus léger, plus efficace, plus rapide, sachant que la lenteur de l'éditeur de VS Code est quand même un peu critiquée et la lenteur des LLM est aussi critiquée. Je comprends que tu puisses aller sur une optique de vitesse. Je n'achèterais pas pour ça, mais j'entends que certains développeurs aiment bien un truc léger, rapide, efficace.

Matthieu : Au moment où on enregistre, ça fait quelques jours que Windsurf a été racheté par OpenAI, c'est ça ? Ou c'est encore une promesse ?

Eric : J'ai entendu un rachat avec une somme assez importante. Je me dis que j'aurais peut-être dû faire des éditeurs de texte à l'époque d'Atom. Il y a peut-être un coche raté, c'est trop tard.

Assistants de code : GitHub Copilot

Matthieu : Pour rappel, les répondants ont répondu à quel moment ? Ça bouge énormément et si on reposait la question dans trois mois, les réponses seraient différentes.

Eric : À peu près il y a un mois, on va situer ça à avril 2025. On a Cursor loin devant, que ce soit sur l'usage ou le sentiment des gens. Ça c'est pour les spécialisés parce qu'évidemment si tu ouvres à tout le monde, tu retrouves VS Code à 41 %, donc même plus en termes d'utilisation que Cursor. Pas forcément avec Copilot, c'est-à-dire qu'il reste l'IDE privilégié des gens qui nous répondent. 41 % sont plutôt VS Code, ce qui fait qu'il y a un avenir pour les solutions qui sont intégrées à des éditeurs de texte traditionnels.

GitHub Copilot vient en deuxième dans la liste avec 19 % des répondants qui disent l'utiliser. On l'a mis dans IDE, c'est super dur d'expliquer que c'est un assistant de code dans un IDE normal. Quand tu mixes les deux, le couple VS Code / GitHub Copilot, même si on ne l'a pas mis en spécialisé, il est très fort, voire peut-être pas loin d'être majoritaire ou en tout cas dans le deuxième avec Cursor.

On découvre aussi des réponses comme NeoVim qui fait un bon quatrième, ça me fait toujours rire. C'est la reprise de Vim mais avec une architecture logicielle modernisée pour qu'il soit plus extensible, mais avec le même esprit d'un éditeur de texte ultra-minimaliste. On a quand même 10 % de répondants qui nous disent utiliser NeoVim. Dans l'écosystème Next, ça a été un peu repopularisé par Lee Robinson qui est le directeur produit chez Vercel. Je ne sais pas du tout s'il y a de l'IA dans NeoVim, probablement quelqu'un a fait un plugin pour.

Celui que j'aime beaucoup dans cette liste, c'est Cline, qui arrive en sixième de notre catégorie "les autres IDE" avec 5 % de répondants. Là où je l'aime bien, c'est qu'il est open source entièrement. C'est un peu un GitHub Copilot open source. Comme il est open source, vous pouvez aller voir la source et en 2025, aller étudier la source d'un agent de code qui vous aide à programmer, c'est juste génial. On peut aller se plonger dans l'implémentation de cet agent, ça veut dire que vous pourriez apprendre un peu comment on fait et comment le faire vous-mêmes ou comprendre ce qui se passe sous le capot de toutes ces autres solutions IA qui ne sont pas du tout open source. C'est vraiment un projet super intéressant.

Après on a IntelliJ si vous êtes en entreprise, on a un plugin Avante.nvim, il faudrait voir ce que c'est. On a Bolt qui s'est retrouvé dans les IDE. Ça je pense que c'est quand les répondants nous proposent des réponses et on les met. Il y a des gens qui considèrent Bolt comme leur IDE. Comme tu peux éditer ton code en live, peut-être qu'ils ne sortent jamais de Bolt. On en reparlera dans sa propre catégorie. On a un peu de stats et pour les pain points, on a le contexte qui revient en point de difficulté.

Matthieu : On a beaucoup moins les hallucinations, mais parce que ce n'est peut-être pas forcément sur l'IA que tu les interrogeais ici.

Eric : Parce que ce n'est pas ton assistant de code qui hallucine, c'est plutôt ton LLM qui est le moteur sous-jacent. Par contre dans l'éditeur de texte, tu vas pouvoir voir les problèmes de contexte où tu ne vas pas pouvoir mettre tous tes fichiers ou il va y avoir des problèmes. Il y a la distraction aussi, 14 % des répondants (78 sur 550) qui nous disent qu'ils sont distraits, que c'est un peu intrusif. Et 11 % qui nous disent que ce n'est pas donné. J'ai GitHub Copilot gratuit en tant que contributeur open source, ce qui me fait toujours rire parce qu'on a entraîné un truc qui vaut plusieurs milliards et qui est un peu l'avenir du code sur la base de ton code source, donc on va te donner l'abonnement à 10 € par mois pour te remercier. C'est mieux que rien, je ne me plains pas, mais ça peut être cher à l'échelle.

Assistants de code : GitHub Copilot domine le marché

Eric : On reste dans le même monde, ce sont plusieurs façons de l'aborder. On va parler des assistants de code. Avant on a parlé du modèle (le moteur sous-jacent), de l'éditeur de texte (la surcouche logicielle autour) et l'assistant de code (un logiciel construit sur le LLM qui t'aide à programmer). On retrouve enfin notre GitHub Copilot en majorité avec quand même 71 % des répondants qui disent avoir utilisé GitHub Copilot. Avec 12 % d'insatisfaction et le reste en neutre ou positif (31 % en positif). Comme Chat GPT dans le monde du code, c'est GitHub Copilot qui domine quand même les assistants de code.

Matthieu : Est-ce que les gens sont contents ? On peut comprendre la dominance de Copilot parce que c'est intégré dans l'éditeur le plus utilisé, mais est-ce que c'est vraiment bien ?

Eric : Ça en a l'air, les gens ont l'air d'être contents. Tu as 34 % de sentiments positifs, alors que le deuxième c'est Supermaven avec 12,8 %. Sachant que pour les autres, il y a un potentiel puisqu'ils sont moins utilisés, on verra aussi ce que ça donne. Mais les devs sont plutôt satisfaits de Copilot. Cursor n'est pas dans la catégorie parce que vous ne le considérez pas comme un assistant de code.

Eric : C'est plutôt ton IDE. Je ne sais pas exactement ce qu'ils font au niveau assistant, il y a une certaine opacité. Ce sont des réponses qu'on peut avoir en étudiant la solution, mais ce n'est pas très clair ce qu'il y a en fait entre l'éditeur de texte qui est devant le développeur et le modèle LLM qui est chez un hébergeur. Sur GitHub Copilot, ils ont leur propre déploiement des modèles qu'ils proposent dans Copilot, géré par GitHub. Ce qui est entre les deux est un peu flou. On ne sait pas exactement à quel point le prompt est retransformé pour faire un travail de pré-traitement et de post-traitement pour fournir une recommandation pertinente. Ce n'est pas toujours très précis ou transparent. Finalement, tirer le trait entre l'IDE, le modèle de fondation et l'assistant de code est assez difficile.

Matthieu : Pour les plus curieux, ce matin il y avait un article sur Human Coders News sur comment Cursor indexe la codebase. C'est publié le 12 mai je pense. N'hésitez pas à y revenir, il y a un article assez détaillé sur comment il fait les chunks, comment il indexe, comment il protège ce qu'il protège ou pas.

Eric : Techniquement, pour moi quand tu dis ça, tu parles d'un assistant de code. Tu es sorti de l'IDE. Je pense qu'il y aura une grosse réflexion sur la prochaine enquête sur ces classifications qu'on a trouvées quand même très difficiles. Soit on supprime toute forme de classification, mais du coup on compare Chat GPT, GitHub Copilot et Perplexity, donc un modèle LLM, un assistant de code et ce qu'on appelle un RAG (un moteur de recherche plus un LLM couplés ensemble). C'est super dur. J'espère que ça sera clarifié d'ici l'année prochaine.

On retrouve des choses cohérentes avec la popularité de ces outils. Éditeur de texte le plus utilisé, solution qui est la plus intégrée, c'est logique de le retrouver là. Après on a plein de gens que je ne connais pas : Tabnine, Supermaven, Amazon Q Developer, Codeium, Xcodeium, Aider. Si vous cochez toutes les cases en connaissant ces outils, c'est super, vous êtes à la mode. Les technologies sont choisies dans un processus ouvert, on a un GitHub Devographics et tout le monde peut contribuer aux enquêtes. On va solliciter des gens qui connaissent un peu le sujet pour nous donner aussi des listes d'outils qu'ils souhaiteraient voir intégrés en amont de l'enquête.

Dans les autres, on retrouve Codeium. Comme on a Codeium qui a changé de nom, je crois qu'il revient deux fois. On retrouve Cline avec 17 % d'utilisation en assistant de code, mon préféré parce qu'il est open source. On a même Codeium en huitième place avec une faute d'orthographe qui est probablement le même. Je suis vraiment désolé pour les gens qui doivent faire de la veille technologique sur ce sujet, ça leur donne un boulot à plein temps.

Matthieu : C'est trop bien de faire cet épisode aussi et l'enquête, parce que du coup ça bouge tout le temps et on comprend que c'est un métier quasiment à plein temps d'être au courant. Vous faites un premier filtre et là on traite ces infos, c'est trop bien pour les gens qui nous écoutent. On peut juste écouter l'épisode et déjà avoir une idée du top 3 des IDE utilisés.

Eric : Les points de difficulté : hallucinations, contexte, intrusif/distrayant. Vous l'avez compris, c'est vraiment le top 3 des problèmes qu'on a. C'est un LLM qui raconte n'importe quoi de façon un peu intrusive et qui en plus n'arrive pas à lire toute la base de code. En fait, c'est un peu un collègue insupportable et très dissipé aujourd'hui. Une critique que je voyais souvent sur les LLM était le fait qu'ils n'étaient pas au courant des nouveautés. Toi qui fais du Next.js par exemple, tu dois le voir. Une nouveauté sort et ton LLM ne la connaît pas, il ne te propose pas ça avant un petit moment. J'imagine que c'est peut-être dans la catégorie "code de piètre qualité". C'était un argument qui revenait souvent : si tu fais des trucs vraiment récents, tu es bloqué tout le temps.

Eric : J'avais fait un article en essayant de faire du Next avec GitHub Copilot et il ne sait pas écrire du App Router parce qu'il faut savoir que les LLM, comme ils coûtent très cher à entraîner, ils ont une date de coupure sur la date des données disponibles. À ce jour, début 2025, on va dire que ce cut est fin 2023. Tout ce qui s'est passé en 2024, un LLM n'est même pas au courant, ça ne fait pas partie de son jeu de données, sauf s'il se retrouve avec des choses qui n'étaient pas datées mais il ne connaît pas. Donc toutes les évolutions de Next, toute la disruption avec l'App Router, il n'est pas tout à fait au courant. Ça évolue à chaque génération de modèle, mais tu auras toujours une latence assez longue. C'est pour ça que l'utilisation directe d'un LLM ne marchera jamais en génération de code, il faut au moins un assistant de code qui est capable d'aller intégrer du contexte, d'aller chercher la doc, etc.

GitHub Copilot a beaucoup bossé là-dessus en réponse aussi à l'émergence de Cursor, d'une compétition. Pendant tout un temps, ils n'avaient pas de compétition. Ils ont bossé en réponse à ça pour mieux prendre en compte le contexte, créer plein de fonctionnalités d'ajout de contexte où tu lui fournis la documentation à jour et là ton LLM commence à être intelligent. Mais parler de code avec Chat GPT via l'interface sans connexion à Internet, pour moi ça ne sert pas à grand-chose, uniquement si tu poses des questions sur la librairie standard Python, là il va être très bon. Mais tout ce qui est d'actualité, tout ce qui est framework récent, ça ne va pas marcher. Ce n'est pas fait pour.

Outils de génération de code : V0 et Bolt

Matthieu : On passe aux outils de génération de code. Qu'est-ce que vous avez mis dans cette catégorie-là ?

Eric : On sort un peu de l'éditeur de texte. Ces outils de génération de code sont plutôt des SaaS, des logiciels spécialisés pour la génération d'une application complète. Ils partent vraiment de rien et génèrent l'application. Alors que l'éditeur de texte, c'est mon workflow traditionnel de développeur, je travaille au quotidien et j'ai l'IA qui m'aide. Là c'est "j'ai une page blanche et je veux créer une nouvelle application", typiquement une application web dans le cadre de cette enquête.

Ce sont des cas d'usage comme le prototypage, le développement ultra-rapide, du fameux "vibe coding" où je n'ai pas forcément de compétences de dev très développées mais je vais essayer de produire quelque chose de fonctionnel pour faire mes tests. On est sur cette catégorie d'outils. Les deux gros dont on doit absolument parler sont V0 de Vercel avec 26,5 % des répondants qui l'ont utilisé et 23,7 % qui en ont entendu parler, et le deuxième c'est Bolt avec 13,3 % d'utilisation et 28,9 % qui en ont entendu parler.

Je les trouve très intéressants parce qu'il faut aussi parler des sociétés qui sont derrière. V0 est un outil créé par Vercel. Vercel est la société qui crée Next.js et qui est aussi un hébergeur spécialisé dans le serverless. Pour résumer, le serverless est un mode d'hébergement où le site est découpé en pages ou en routes qui sont indépendantes, et ça lui permet de passer à l'échelle de façon très efficace. On utilise Vercel par exemple pour le State of parce que ça tolère bien les pics de demande sur des points d'entrée. Ce sont des gens qui savent faire une appli web et qui savent l'héberger.

Bolt est fait par StackBlitz. StackBlitz est l'entreprise qui développe la technologie de Web Containers. On leur a confié le développement de ce standard, sa mise en œuvre. Ce sont des gens qui ont pour expertise de savoir exécuter n'importe quoi dans un navigateur web. On peut faire tourner du Next.js dans un navigateur web en utilisant les Web Containers. Ils ont fait un framework de tuto qui est génial, ça permet de faire du Next sans aucune installation et qui tourne chez toi dans ton navigateur. C'est quand même génial pour faire des démos, pour montrer des patterns. J'ai monté un site sur ce principe qui s'appelle Next Patterns.dev où je montre quelques failles de sécurité, par exemple par rapport au meetup dont on parlait sur Montpellier la semaine dernière.

Du coup, ce n'est pas étonnant de les retrouver dans l'IA parce qu'ils ont tous les ingrédients pour savoir créer des IA qui génèrent du code, parce qu'ils sont en capacité de tester ce code, de tester facilement du code qui a été généré par une IA. Ils sont en capacité aussi de comprendre ce qu'est le développement web, ce qu'est une application web de façon extrêmement profonde. Il n'y a aucune surprise à les retrouver comme les deux acteurs majeurs dominants sur le marché de la génération d'applications web à partir de l'IA. Ils ont vraiment vu le filon, ils avaient toutes les compétences pour et ils ont cartonné.

Matthieu : Ce qui m'étonne peut-être est à quel point c'est utilisé chez les devs. J'ai probablement une vision très médiocre de ce que c'est. J'ai dû mettre un prompt dans V0 il y a six mois et avoir un effet "waouh" où tu dis "OK, la page qui sort elle est hyper propre", mais je crois qu'à l'époque je ne savais pas trop ce qu'on pouvait en faire après. Je comprends bien qu'il y a un intérêt si tu es entrepreneur et tu veux faire une landing page, trop bien. En tant que dev, une fois que tu as généré ta page sur V0, c'est quoi la suite ?

Eric : La suite, c'est que tu la clones en local et que tu reprends tout ce qu'il t'a généré. En gros, il est quand même plutôt spécialisé historiquement, ils sont partis plutôt du frontend, donc il te génère une interface. On va dire qu'ils remontent progressivement vers le backend. Ils sont vraiment sur l'application web au sens littéral, il te génère une interface avec des pages, avec des menus, avec un certain nombre de composants et puis éventuellement un backend derrière pas trop lourd.

Bolt va t'inciter lourdement à te brancher à Supabase (ou Superbase pour ceux qui veulent chercher), c'est-à-dire une espèce de Firebase open source, donc un backend clé en main que tu gères avec une interface graphique qui gère la base de données, les utilisateurs, les connexions. Toute cette partie backend se branche très bien avec ce type d'outil. La suite typiquement, c'est que tu reprends, tu clones chez toi, tu sors de Bolt. Tu n'es pas censé vivre et développer éternellement dans l'interface de Bolt, c'est plutôt pour mettre en place ton appli. Par contre ça évolue vite. Si tu as testé V0 il y a quelques mois, la course ils vont en fait sur une sorte de course au fullstack pour générer des backends fonctionnels ou s'interfacer avec des outils qui permettent de le faire. C'est plutôt ça l'optique de ces outils-là.

Matthieu : Ça se bataille presque avec un agent de Cursor par exemple, parce qu'on est à peu près sur la même valeur ajoutée.

Eric : Cursor va avoir du mal, même GitHub Copilot, ils vont avoir du mal à te générer une appli de zéro. Ce n'est pas forcément leur spécialité. Si tu dis "je veux une appli Next", typiquement il faut quand même reconnaître que dans le web il y a plein d'usages qui sont de type liste, formulaire, vue détaillée (opérations Créer, Lire, Mettre à jour, Supprimer, afficher des listes, faire des recherches administratives). Cursor ne va pas savoir te générer ça entièrement, il va te le faire un peu fichier par fichier, il va falloir que tu le guides. Ça va être plus facile de générer ce type d'appli avec Bolt et puis après de l'ouvrir dans ton Cursor pour ensuite retravailler fichier par fichier.

Pour être utilisateur de Cursor, je pense que ça bouge parce qu'ils ont fait de gros progrès sur ce qu'ils appellent les agents. Maintenant il est quand même assez débrouillard pour mettre un peu un socle en place. Pour ce truc-là, il faut que je crée quatre fichiers JS, puis un CSS, puis un HTML, puis que je crée le truc et il peut lancer la génération en parallèle. Peut-être qu'il y a une limitation sur la taille, mais il n'est pas mauvais pour faire des socles un peu techniques comme ça. Il n'y a pas les images, c'est que du code. Peut-être que V0 et tout apportent un plus qui est très graphique.

Eric : Exactement, ils se recoupent et GitHub Copilot sur la dernière version de VS Code a sorti aussi un mode agent. Je ne sais pas s'ils le considèrent encore comme expérimental, je crois que c'est bon sur cette version. Ils réagissent à cette compétition parce que ça finit par se recouper et c'est vrai que du coup les IDE et les assistants de code existants vont essayer d'aller vers la génération d'applications. Tout ça finit par se recouper pour essayer d'avoir un peu tout le marché chez soi.

Matthieu : J'ai une question naïve : j'en entends parler de loin de V0 que je n'ai pas utilisé, mais je le vois vraiment sur la partie front, sur la partie en particulier vu que c'est les éditeurs de Next, tout ce qui est React. Est-ce que ça a du sens d'utiliser V0 en dehors de cette stack-là ? De dire "je veux bootstraper une application, un petit prototype, mais sur une autre techno", mettons Django/Python, est-ce que ça a aucun sens ?

Eric : Effectivement, tu es plutôt dans un écosystème de développement web, mais développement web entendu par les développeurs JavaScript qui pensent qu'il n'y a que ça sur terre. V0 est forcément marqué Next.js. Bolt te génère très bien des applications avec Vite, qui est le système de build utilisé par beaucoup de frameworks JavaScript dont Astro JS par exemple. Il te génère aussi assez bien des applis Next. Tu es quand même plutôt sur du frontend JavaScript Next/React avec des backends légers, voire ce qu'on pourrait appeler du Backend For Frontend. Next.js est un framework fullstack, mais ça part toujours des frontends historiquement, c'est ancré. C'est moins marqué génération d'appli backend pur ou voir d'autres langages Python, etc. Clairement, on est dans du Web JS, du frontend fullstack JS plutôt.

On peut avancer juste pour mentionner les suivants : Replit, Lovable, Open UI. Tu as quelques challengers pour que l'innovation se poursuive. Les pain points : code pas très qualitatif arrive loin devant. Code un peu pourri. Après, si tu veux, il faut aussi apprendre à les prompter. S'il te génère un code pas terrible, il a tendance à tout mettre dans un gros fichier du premier coup, tu lui dis "OK, refactor maintenant", et il refactor. Il sait aussi s'améliorer juste sur demande. Il ne faut pas négliger ça. Et après le deuxième, c'est "pas très utile" (15 %). Finalement, est-ce que j'ai vraiment tellement gagné du temps par rapport à un template où j'aurais juste codé mon truc, ou à la limite avec un je me serais mis dans Cursor à partir d'un template, j'aurais peut-être été aussi vite. Ça reste quand même un feedback à laisser évoluer pour ces outils.

Langages de programmation et IA

Eric : On a fait un peu les grandes familles d'outils. On a eu le modèle, l'éditeur de texte, l'assistant de code et puis cet outil un peu à part qui est la mise en place de ton appli web entièrement par un générateur d'applis. Là on arrive aux outils un peu plus généraux qu'on va pouvoir utiliser pour tout un tas d'usages.

On s'était un peu pris la tête pour formuler la question : "quels langages de programmation utilisez-vous avec les outils IA ?". Est-ce que ce sont les langages qui sont générés par les outils dont on a parlé avant, ou est-ce que ce sont les langages qu'on utilise pour manipuler des outils IA ? C'est plutôt "sur quel langage de programmation tu appliques l'IA ?". Nos répondants sont des développeurs JS majoritairement. Ça se voit nettement, on a 80 % de JavaScript et 80 % de TypeScript. La plupart des développeurs JavaScript font du TypeScript dans cet écosystème donc c'est un peu pareil.

Python arrive en troisième avec 38 %, ce qui n'est pas illogique. Python est le langage de la science de données, le langage des LLM, le langage des frameworks de connexion au LLM, c'est quand même plutôt ces technologies-là qu'on utilise pour créer de l'IA traditionnellement. Je dis bien traditionnellement parce que comme il y a beaucoup d'usage pour le web, beaucoup d'applications sont en SaaS, tu as quand même JavaScript qui est très présent et tu as de plus en plus de frameworks JavaScript pour l'IA, en tout cas pour l'IA générative tu as beaucoup de connecteurs qui émergent.

On a quand même Bash qui arrive en quatrième, je veux bien qu'on en parle parce que celui-là je ne l'avais pas anticipé. C'est super représentatif parce que c'est 569 réponses sur 3527, donc 16 % des répondants, ce n'est pas une erreur. Écrire des scripts Bash, c'est parfois nécessaire pour du backend pour trier des fichiers, pour plein de trucs. C'est aussi nécessaire que c'est atroce parce que c'est un langage horrible qui a 50 variantes, shell, bref tu as tout un foisonnement de façons de l'exécuter avec des syntaxes légèrement différentes. Du coup, je ne suis pas étonné qu'il y ait un peu de génération de scripts. Ou alors c'est juste des gens qui font des scripts pour pirater d'autres gens, peut-être. Tu peux peut-être avoir des mini-scripts d'appel à Ollama en local. Ou c'est juste que c'est relou à écrire et donc tu passes directement à l'intelligence artificielle pour ton code Bash. En tout cas on a une population au même niveau que PHP.

Il y a peut-être aussi une réponse à choix multiple : par exemple je suis dev Ruby, il y a du front JS et j'ai besoin de faire un peu de DevOps pour déployer mon appli à la main sur un serveur, j'ai peut-être besoin d'un peu de Bash, un peu de JavaScript, un peu de Ruby, et finalement je vais cocher les trois cases. On peut quand même dire que tu as une bonne représentation des langages backend : 38 % de Python, PHP à 16 %, Go à 12 %, Java à 11 %, Rust à 10 %. Rust, tu es même potentiellement carrément sur du logiciel ou des librairies. 7 % de C, du Ruby. On a un peu de mobile qui vient derrière : Kotlin, Swift, Dart, etc.

C'est peut-être plus disparate mais au final si tu fais la somme des répondants, même s'il y a un peu d'intersection, tu as quand même beaucoup de développeurs backend dans les réponses. C'est assez logique parce que c'est encore assez coûteux avec le matériel qu'on a d'embarquer directement des LLM sur nos appareils. Généralement on fait appel à des API. C'est probablement une mauvaise idée d'appeler une API côté client pour des raisons de quota ou autre, donc c'est finalement souvent le backend qui va faire l'intermédiaire. Ça explique aussi peut-être la génération de code backend avec l'IA dans cette réponse aussi tout simplement. Tu as quand même des gens qui génèrent leurs classes Java avec l'IA, ce n'est pas qu'un truc de dev JavaScript. Ils sont forcément sur-représentés parce que c'est le langage le plus parlé avec Python. Ça ne veut pas dire que le backend a disparu et qu'on ne génère qu'un type de langage, il n'y a pas du tout d'homogénéisation là-dessus. Chacun continue à travailler sur sa stack traditionnelle et intègre l'IA dans sa stack, je pense.

Génération d'images et bibliothèques IA

Eric : On a d'autres sujets, la génération d'images. C'est le domaine qui bouge le plus, c'est très difficile. On a une majorité de DALL-E avec 42 % de répondants, mais c'était avant la sortie de GPT-4o et du modèle image sous-jacent. Le modèle sous-jacent est GPT Image 1. En gros, c'est le truc qui fait les start-up kits et les studios Ghibli sur LinkedIn, c'était juste avant. En termes de qualité, le saut est tellement phénoménal qu'on peut s'attendre sur une prochaine enquête à voir ces outils remplacer DALL-E. DALL-E reste très populaire dans nos réponses.

Après on a Midjourney à 31 % et Stable Diffusion à 24 %. Après on a du Grok à 9 %, je soupçonne une réponse de radin parce que Grok est un modèle horrible, c'est le modèle de Twitter, sans filtre, sans protection contre les biais, c'est une horreur mais complètement gratos. Donc je soupçonne quelques radins parmi les répondants ou des gens qui sont encore sur Twitter.

Après on a Adobe Firefly, c'est une bonne surprise. Je suis un peu ce que fait Adobe, Adobe Express et Adobe Firefly. C'est un peu leur suite qui intègre beaucoup de générations à partir de l'IA. Je trouve que c'est un outil assez prometteur pour la génération d'image, le graphisme assisté par l'IA, c'est assez intéressant.

Il y en a un dernier que je citerais, c'est Flux, seulement 2 % de répondants (73 sur 3513), mais pourquoi je le mentionne ? Parce que c'est un modèle de Black Forest Labs, de la Forêt Noire, donc un modèle allemand qui, comme Mistral, a l'avantage d'être un modèle souverain et qui est maintenant intégré à Mistral. Ils ont un partenariat, Flux est ce modèle-là qui génère les images de Mistral. Si vous restez sur une stack européenne pour des raisons de RGPD, de conformité, de certains cas d'usage (droit, sécurité), on a besoin d'avoir cette contrainte de localisation, donc c'est cool d'avoir des acteurs chez nous. Flux est le modèle API sous-jacent. Je suis le pro d'aller fouiller le modèle pour voir s'il a une API sous-jacente, ça m'agace un peu quand on me vend une plateforme, j'ai envie de savoir qui est le modèle derrière parce que derrière une plateforme il peut y avoir tout et n'importe quoi. Les données peuvent partir n'importe où. C'est quand même assez bien de s'intéresser à ces acteurs-là. C'est important d'en préserver sur le territoire.

Après on a Leonardo, je ne connaissais pas. On a Bing, je ne savais pas qu'ils faisaient de la génération d'image. Imagen 3, Ideogram.

Là on aborde une section que j'aime bien, ce sont les libs qui permettent de te brancher à un LLM. Enfin on fait du code ! On fait du code pour intégrer les LLM à ses applications. Avec ces outils-là, on peut créer nos propres assistants de zéro, on peut coder nos propres solutions fondées sur les LLM de façon totalement libre. Ce sont des librairies qui nous aident à nous brancher au LLM de façon directe, qui nous aident à structurer cette communication avec le LLM.

Parmi nos répondants, on a 12 % de répondants qui mentionnent avoir utilisé le Vercel AI SDK. Il n'a pas vraiment de nom, c'est comme appeler sa tondeuse "la tondeuse", le SDK Vercel AI c'est le Software Development Kit, donc en gros la librairie de développement pour faire de l'IA de Vercel. Ils ne se sont pas trop foulés sur le budget naming. Elle est a priori plutôt dominante dans l'écosystème JavaScript, elle l'est chez nos répondants en tout cas. C'est un peu celle que je retrouve le plus dans le JS. Super bien documentée, j'invite vraiment tout un chacun à aller chercher la doc parce que vous allez vraiment apprendre comment on parle à un LLM pour de vrai, comment on fait du vrai prompt engineering de pro, comment on raisonne en termes d'agents et comment on dépasse le fait de juste parler à la boîte de dialogue de Chat GPT. C'est quand même super intéressant.

On a Transformers.js. Pour ceux qui découvrent l'écosystème LLM, Transformer est l'architecture de réseau de neurones profonds qui est sous-jacente au LLM. Les LLM ont été rendus possibles grâce à cette architecture parce qu'elle fonctionne bien sur des très gros modèles, alors qu'avant on ne pouvait pas faire des modèles aussi gros ou en tout cas ça n'avait pas d'intérêt. Ça a cassé ce verrou et on a pu se mettre à faire des réseaux de neurones de taille aussi grande qu'on veut. C'est ça qui a donné les LLM. ONNX Runtime est un peu plus particulier, ONNX est une librairie de réseau de neurones profonds.

Et pour finir un peu sur un truc qui n'est pas le premier mais qui me tient à cœur, c'est LangChain. On a 2 % de répondants (56 réponses sur 3171). LangChain est quand même plutôt un truc de l'écosystème Python, donc ça s'explique qu'on l'ait un peu moins. Mais il y a une version JavaScript. Au-delà de LangChain, il y a une deuxième solution qui s'appelle LangGraph qui est liée, faite par la même société LangChain. LangChain / LangGraph, on peut les mettre un peu dans le même paquet. C'est ce qui permet de créer des agents et c'est l'acteur majoritaire en Python. Il est, d'après notre enquête, un peu plus confidentiel chez nos répondants dans le web, mais je tiens le pari que l'année prochaine on verra une explosion de l'utilisation de LangChain / LangGraph dans l'année à venir en termes d'usage. Après on a les SDK des fournisseurs, le SDK OpenAI, Mistral va avoir son SDK, Anthropic aussi.

Pour LangChain, moi c'était un biais de développeur backend que je suis, j'entendais qu'il y avait de plus en plus d'implémentations qui étaient faites dans différents langages backend. Je ne sais pas ce que ça vaut, si c'est aussi complet que le LangChain Python ou JS qui sont extrêmement complets et ont beaucoup de contributeurs, mais il y en a en version PHP, en Ruby. Naturellement si je dois faire du développement en passant par un LLM, j'aurais tendance en Ruby, qui est mon langage, à passer par LangChain par exemple. C'est très intéressant parce que ça permet de faire beaucoup de choses, du RAG facilement ou de pouvoir prédire exactement la sortie, avoir des sorties structurées, c'est très agréable à utiliser.

Eric : Complètement, je pense que par exemple le Vercel SDK OK mais tu es dans l'écosystème Vercel/Next.js/React, tu as des hooks pour te brancher à React côté client. Mais si tu vas sur du backend, LangChain est quand même un acteur un peu majoritaire. Python est la base, donc c'est le plus répandu, la version vraiment officielle. JavaScript est supporté officiellement. Il peut y avoir des petites variations dans l'API mais a priori il reste populaire en JavaScript, notamment parce que tu vas aussi avoir besoin d'avoir une connexion côté client. Tu veux avoir le même langage client, le même langage serveur, tu es développeur Node.js, LangChain JS ça marche très bien. Je l'utilise peu, c'est vrai que quand je vais en JS j'ai tendance à aller chez Vercel. Je n'ai pas trop utilisé LangChain JS mais je sais que j'en ai des bons retours. Tu as LangChain Go qui est une nouvelle implémentation. Le reste est plutôt la communauté qui le maintient. Mais ça devient une sorte un peu de standard quand tu n'as pas encore choisi ton LLM, que tu ne veux pas être couplé à un écosystème précis, tu passes sur LangChain et tout va bien.

APIs navigateurs et usages locaux avec Ollama

Eric : Après il y avait une petite question sur les API navigateurs : "quelles fonctionnalités IA aimeriez-vous voir arriver dans le navigateur ?". On a eu une discussion aussi avec des responsables chez Google pour savoir ce qu'ils se demandent justement ce qu'ils vont mettre dans Chrome au niveau IA intégré directement chez vous, côté client en local, peut-être de façon privée aussi (ce qui est quand même un gros besoin). On a la traduction qui ressort en premier avec 62 %, la synthèse de texte, la génération de sous-titres, la reconnaissance de discours, la détection de langage du site, la vision par ordinateur. Ce sont des fonctionnalités qu'on voudrait avoir directement dans son navigateur, dans les API, et qu'on pourrait intégrer à nos applications clientes et frontend par exemple. On note pour Arc que je ne connaissais pas.

Parmi les autres outils, un peu les interfaces pour s'interfacer avec des LLM surtout en local. Celui qu'on peut mentionner est Ollama avec 13 % de répondants, qui va te permettre de faire du LLM sur ton ordi. Si tu as un processeur suffisamment puissant, voire si tu as une infrastructure dédiée avec carte graphique, tu peux utiliser un outil comme Ollama pour gérer tes modèles open source, les installer, les télécharger et les exécuter de façon simplifiée. ComfyUI, que j'ai utilisé pour générer des images ou tenter d'en générer, mais très peu compatible avec Mac et du coup extrêmement lent et donc très décevant. L'interface est atroce parce que c'est vraiment des graphes qu'on dessine. Désolé si vous êtes sous Mac, ça ne va pas être possible à moins qu'ils aient changé un gros truc depuis. Souvent c'est l'inverse, c'est sous Ubuntu que je manque d'outils. Désolé d'être un développeur, un vrai dev. Un Mac ça reste cher, c'est super pour l'IA au niveau matos mais ça reste en matériel personnel/professionnel le mieux et ça reste un peu coûteux. Pour l'instant, je trouve que les API, l'hébergement cloud, c'est aussi bien parce que ce n'est pas limité en puissance de calcul finalement et ça marche bien et ça évite de démultiplier du matos extrêmement coûteux si on n'a pas des usages hyper intensifs. C'est encore un peu émergent tout ça.

Usages réels de l'IA

Eric : Pour finir un peu sur ce que vous faites de tout ça, finalement les développeurs on a parlé des outils qu'on utilise mais on les utilise pour quoi ? Le cas d'usage qui revient dans notre enquête, c'est un peu logique, c'est la génération de code avec 91 % des répondants. Ensuite, "Learning and Research" pour l'apprentissage, 66 % des répondants. Là je mets quand même un bémol. Disons que la recherche au sens moteur de recherche avec un LLM, comme on le disait, un LLM est un modèle qui est entraîné et puis il s'arrête d'être intelligent. Donc si vous utilisez directement des Chat GPT sans connexion à Internet, sans un abonnement qui le pousse à faire de recherche sur Internet, ça ne va pas être terrible. Si vous l'utilisez et qu'il fait des recherches sur Internet, ça ne va pas non plus forcément être terrible parce que ça reste un modèle d'IA. Par exemple, il va chercher le top 5 des résultats de recherche, il va les synthétiser mais il n'est pas très bon en fait pour vérifier que le top 5 était vraiment pertinent. C'est-à-dire qu'il va toujours vous donner les 5 résultats de recherche qui sont tombés pour la requête, mais il n'est pas capable de dire "en fait je n'ai rien trouvé de pertinent". Par exemple, si vous posez une question d'ordre légal, même administratif ou réglementaire dans une entreprise, les réponses sont vraiment pas terribles, y compris avec Perplexity, y compris quand il cite ses sources, parce qu'il rate en fait des détails, des points de détails qui font que souvent les docs ne s'appliquent pas exactement à votre concept, à votre contexte, ne répondent pas à votre question. Soyez prudents sur cet usage apprentissage et recherche. Ce n'est pas un outil qui est vraiment fait pour ça.

Matthieu : Je peux ajouter peut-être un truc là-dessus. Dites-nous si vous voulez qu'on fasse un épisode carrément dédié. Human Coders est un centre de formation, on fait des formations de quelques jours (par exemple vous pouvez vous former avec Eric à Next.js). On a remarqué en discutant avec quelques formateurs qu'il commence à y avoir des participants qui arrivent avec Cursor, Windsurf et autres. Généralement la première journée, tous les exercices de la première journée sont résolus très facilement par toutes les IA du marché. On voit nos formateurs qui commencent à avoir des comportements différents : soit c'est totalement OK et ça fait partie du jeu, soit la première journée ils ont plutôt tendance à recommander de ne pas l'utiliser histoire de le faire à la main. On se questionne vraiment sur est-ce que la façon d'apprendre ne va pas changer. Je remarque à titre personnel que l'IA a radicalement changé la façon dont j'apprends. Il y a plein de détails dont je ne m'attarde plus à connaître au début parce que je sais que je vais avoir l'IA qui va servir de petites roues. Par exemple Three.js qui est très verbeux, je voulais faire un truc très précis et en fait il y a plein de choses où je me dis "OK, j'ai vaguement compris comment ça marche, il y a quelques lignes à la fin où je ne sais pas pourquoi il faut mettre ça égal à 4, c'est pas grave, je sais que l'IA c'est la base pour elle parce que c'est un tuto et donc je vais la laisser me proposer ça et je peux me concentrer sur l'essentiel". On se pose vraiment la question de s'il ne faut pas petit à petit qu'on adapte la façon dont on apprend à nos participants parce que l'usage des LLM commence à être massif et ça risque d'augmenter. Est-ce qu'il ne faut pas dire "OK maintenant c'est un standard et donc on va apprendre un peu différemment" ? On pense faire peut-être une interview ou un petit débat à plusieurs sur ce sujet. En tout cas, je vois qu'il y a un changement radical là-dessus et c'est assez récent. Jusqu'à maintenant, je pense qu'il y a eu une vague où les gens ont dit "OK, bon j'ai posé une question à Chat GPT, il m'a aidé un peu, c'était pas incroyable", et c'est vrai qu'avec les agents et tout il y a un changement mais il faut le temps que les gens re-testent.

Eric : Clairement. Je suis plutôt team aujourd'hui où je suis plutôt sur un apprentissage sans et en même temps je recommande un apprentissage de ces outils-là en tant que tels. Je vois aussi beaucoup de gens qui à la fois risquent d'apprendre un peu moins bien à coder ou de rater le coche de l'apprentissage mais qui ne sont pas pour autant si excellents qu'on pourrait le penser avec l'utilisation des LLM dans la compréhension de comment on parle à ces outils-là, de comment on tire parti vraiment à fond des éditeurs de texte fondés sur l'IA. C'est une compétence aussi. Je conseillerais quand même aux gens de se former aux deux un peu séparément : d'apprendre Next par exemple, puis après d'apprendre Cursor sur le cas de Next, d'être vraiment un tueur en Cursor qui sort des applis Next super rapidement et de ne pas forcément essayer de mélanger les deux pour finir par être un moyen développeur Next qui ne comprend pas tout ce qui se passe et un moyen développeur Cursor qui n'est pas non plus si productif que ça.

C'est vrai que c'est difficile parce que les différents LLM dont on discute sont de mieux en mieux. Les résultats sont de mieux en mieux donc on a tendance à vouloir se reposer de plus en plus sur eux. Je pense ça reste quand même encore aujourd'hui important de bien comprendre le code qui est généré. Des fois ce n'est pas simple parce que 90 % du code généré va être très bien et du coup c'est parce que je connais bien le langage et je connais bien la subtilité que je me dis "Ouh là, en fait il s'est planté sur cette ligne, il a eu l'air d'utiliser tel truc ou il n'a pas compris telle chose". Peut-être que des développeurs débutants vont peut-être trop faire confiance aux LLM puisqu'ils sont devenus assez bons, au risque à la fin de ne pas comprendre les subtilités du code généré. C'est ça aussi toute la difficulté.

Matthieu : On pourrait même imaginer que ça fasse changer que l'ordre, mais c'est déjà intéressant. Je pense que l'ordre des choses qu'on va apprendre va être un peu différent. Il n'y a peut-être pas nécessité de se concentrer sur la syntaxe ou sur les API d'une lib au tout début parce que l'IA va nous les donner. En fait on les apprendra peut-être parce qu'à force de demander à l'IA un truc bête on va l'apprendre par cœur, ce qui est plutôt agréable d'ailleurs, c'est qu'on va finir par avoir notre cerveau qui fait juste du cache normalement et pas qu'il y ait un début peut-être pas très agréable où il faut apprendre des trucs par cœur. L'ordre va aussi être impacté.

Eric : En génération de texte (62 %), c'est vrai, ils écrivent mal les LLM en français notamment. En anglais je ne sais pas si c'est beaucoup mieux mais ils adorent les bullet points, mettre beaucoup d'adjectifs, "machin et machin et truc et truc", ils ne savent pas s'arrêter à un adjectif clair. Ils font des phrases un peu longues avec beaucoup de propositions. Mais j'ai quand même une réponse à ça : faites un deuxième prompt en lui disant "arrête de faire des bullet points et fais-moi une seule phrase", "quand tu vois une phrase avec deux adjectifs, n'en garde qu'un, garde le premier", "coupe tes phrases en deux". En fait vous allez voir qu'en deux trois prompts, si vous avez un modèle quand même suffisamment qualitatif (je parle quand même plutôt côté Anthropic sur les Sonnet 3.7 par exemple ou anciennement Opus), ça marche mieux sur un modèle de taille moyenne. En quelques prompts vous pouvez lui apprendre à écrire, voire même vous pouvez lui demander d'évaluer la qualité de l'écriture, de sortir des points d'amélioration et de les appliquer. En fait ça peut être phénoménal. On peut obtenir du texte difficile à distinguer de l'humain en quelques prompts. Le tout c'est d'aller un peu plus loin que la génération basique. C'est assez impressionnant.

Synthèse avec 55 % de réponses, traduction 45 %, génération d'image à 38 %. Je précise, génération d'image avant même cette fameuse disruption avant l'arrivée de GPT-4o qui a fait quand même un gros progrès, un changement aussi de technique employée sur de l'auto-régressif au lieu de la diffusion pour être technique, mais qui en a fait un saut, il y avait quand même déjà beaucoup de génération d'image avec l'IA donc c'est quand même assez populaire.

L'usage de la génération de code

Eric : Finalement le bilan, est-ce que vous générez beaucoup de code vous développeurs avec l'IA ? Non, pas tellement. En fait la majorité des développeurs vont produire plutôt autour de 10 %, 15 %, 20 % de leur code qui est généré par l'IA. C'est plus que zéro parce qu'il y a 5 ans ça n'existait même pas. Ça fait quand même à la fois beaucoup et en même temps on n'est pas sur le remplacement des développeurs par les machines. On a encore un peu de marge.

Matthieu : C'est intéressant parce qu'en discutant avec des devs, on a souvent quand même la question (comme on gère un centre et que du coup on peut voir un peu les tendances du marché) : "est-ce que l'IA impacte le marché actuel ?". En fait, c'est une première réponse à ça : les gens qui utilisent l'IA, il y en a aujourd'hui très peu. Donc en fait on est loin d'avoir un bouleversement du marché des devs dû à l'IA, il y a peu de gens qui s'en servent quand on prend l'ensemble des développeurs. On pourrait même imaginer qu'il y a presque un biais sur aussi les répondants, je ne sais pas si les gens qui n'utilisent pas du tout d'IA sont allés répondre à ce sondage donc peut-être que même ces stats sont un peu élevées même par rapport au marché. En fait l'usage est encore très faible. On parle des stats d'avril où Cursor est sur le marché depuis presque un an, peut-être même un peu plus, donc c'est très lent, l'entrée sur le marché est très lente.

Eric : Clairement, on est plutôt dans du sur-représenté. On est des gens qui aiment les effets de mode, qui sont sur Twitter historiquement, sur les réseaux sociaux. On a plus tendance à zoomer. Donc si on n'a pas des gens qui génèrent 80 % de leur code avec l'IA, a priori on n'aurait pas dû capter ces gens. On en a quand même qui nous disent "moi je fais quasiment tout avec l'IA" : on a 88 personnes qui nous disent "je fais 90 % de mon code avec l'IA", 11 qui font 100 %. Je pense qu'ils ont peut-être développé leur première appli avec Bolt ou alors vraiment ils vivent dans le futur.

Les dépenses liées aux outils IA

Eric : Une question pour finir sur les dépenses. Je ne sais pas si c'est intéressant de parler du marché. Finalement, est-ce que vous êtes prêts à payer pour tout ça ? C'est aussi le signe que vous êtes attirés en tant que développeur ou pas. En majorité, vous ne mettez pas d'argent à titre personnel dans l'IA (52 % sur 1800 répondants mettent zéro). On en a qui mettent 1 à 20 dollars (24 % quand même), c'est typiquement un abonnement à une version personnelle d'un hébergeur LLM, d'une plateforme LLM quelconque. On a 18 % entre 20 et 50 dollars.

Par contre, en entreprise, on a plus quelque chose, une répartition un peu hétérogène, et on a 12 % qui dépensent plus de 5000 dollars probablement par mois. Donc voilà, des entreprises qui sont quand même déjà à une certaine échelle, qui sont des gros consommateurs d'IA. Ça existe déjà et on en a eu 280 dans les répondants. Je trouvais ça assez impressionnant, il y a quand même un marché réel de l'outil IA, ce n'est pas qu'une bulle, il y a des clients finaux, des entreprises qui sont clientes de ces solutions.

Matthieu : On a vu au tout début dans la démographie que tu avais pas mal de gens qui venaient de grosses boîtes. Du coup on peut imaginer que si tu as 1000 salariés, que tu leur payes tous un abonnement à Copilot ou autre, on atteint vite des sommes importantes.

Conclusion

Eric : Je pense qu'on a fait un peu le tour des stats clés pour ce sondage et puis à l'année prochaine pour 2026. L'appli sera peut-être générée entièrement par l'IA. On pense à refondre l'appli Next qui est un peu difficile à maintenir pour nous toute petite équipe, c'est-à-dire moi qui ai à peu près aucun temps à y consacrer et qui prie pour que ça continue de fonctionner sans que je fasse rien. Sacha qui gère un truc costaud mondial dans plusieurs pays traduit dans 25 langues tout seul. Donc Next est un peu complexe pour notre toute petite équipe. Peut-être qu'on réécrira la prochaine enquête sur l'IA avec l'IA, on verra, on vous tiendra au courant.

Matthieu : Si tu avais 2-3 points en résumé des principaux trucs qui t'ont marqué dans cette enquête, à ton avis qu'est-ce qu'il faut qu'on en retienne ?

Eric : Je pense qu'il y a vraiment un dynamisme dans l'écosystème, mais en fait des développeurs mais dans tout ce que je vois autour aussi dans toutes les entreprises. On ne peut pas dire que les entreprises, les développeurs soient adverses à l'innovation. On ne peut pas dire que ce soit juste "tout vient des États-Unis, il ne se passe rien en Europe". Non, ça bouge vraiment partout. Tout le monde, développeur, non-développeur, s'approprie ces solutions innovantes et essaie d'en tirer parti pour être plus efficace, pour être meilleur dans leur façon de fonctionner. Je trouve ça plutôt positif, les gens ont envie d'innover, ils ont envie de faire mieux, ils n'ont pas envie de rester de stagner. Ce n'est pas du tout le cas et ça casse tous les stéréotypes. On entend la PME locale qui va rester dans son truc, l'administration... Non non, les administrations publiques s'en emparent, le public s'en empare, le privé s'en empare, les PME s'en emparent, les grosses entreprises paquebot sur des marchés hyper traditionnels s'en emparent extrêmement vite. Ça, je trouve ça assez intéressant parce que je pense que collectivement ça va être bien.

La deuxième remarque, c'est sur l'environnement, la consommation énergétique de ces solutions-là. Je pense que ce n'est pas insoluble, je pense que techniquement ce sont des problèmes sur lesquels on peut progresser. Les LLM marchent parce qu'ils sont gros, donc ils consomment, ça sera toujours un peu le cas, mais je pense qu'il y a une marge de progression qui est réelle. En même temps il faut continuer à mettre la pression sur les fournisseurs sur ces sujets-là. Écrivez à votre support pour dire : "au fait, combien ça consomme ? Je n'ai pas trouvé les statistiques de consommation énergétique de votre LLM". Si on est un million à envoyer ce message au support, les choses bougent en fait, ils ont une obligation de réagir. Il ne faut pas se brider pour ça et en même temps il ne faut pas lâcher le sujet qui va quand même être important. Quand Microsoft veut remettre en route Three Mile Island (qui est un peu le Tchernobyl américain, il y a eu un cœur qui a fondu là-dedans), il faut se poser des questions de ce qu'on fait. Ne rien lâcher sur la partie consommation énergétique des solutions.

Matthieu : OK, merci beaucoup. Si dans les auditeurs et auditrices, il y a des gens qui s'intéressent à ça, on rappelle qu'on a des formations sur le sujet : on a une formation sur Cursor, on a une formation sur les IA pour les développeurs, on a une formation en cours sur LangChain, et pas mal de formations autour de l'IA. Si ça vous intéresse, n'hésitez pas à regarder notre catalogue de formation. On rappelle aussi que tu donnes des formations pour Human Coders sur Next.js et Astro. Si vous avez besoin de formations là-dessus, c'est Eric. En 15 minutes, on génère une appli Next avec Bolt. Voilà donc 15 minutes... non c'est hyper rapide. Merci beaucoup et s'il y a d'autres State of et si vous voulez qu'on fasse les épisodes sur les prochains State of, dites-le nous, ce sera avec un grand plaisir. Merci Eric pour cette analyse, c'était vraiment trop bien. On était très contents de t'avoir avec nous. À très bientôt.

Eric : À bientôt tout le monde. Salut !

Matthieu : Salut tout le monde !