- En développement logiciel, le goulot d’étranglement n’a jamais été l’écriture du code, mais plutôt divers processus centrés sur l’humain comme la revue de code, le transfert de connaissances, les tests, le débogage, la collaboration et la communication
- Grâce aux LLM, générer du code est devenu extrêmement simple, mais le coût et la charge liés à la compréhension, la validation et la confiance ont au contraire encore augmenté
- La génération rapide de code impose davantage de charge aux reviewers, aux personnes chargées de l’intégration et à celles qui assurent la maintenance, sans réellement accélérer la vitesse de l’équipe dans son ensemble
- La compréhension du code reste la partie la plus difficile, et même si les LLM génèrent du code, la qualité ne peut être garantie sans confiance au sein de l’équipe et sans contexte partagé
- Les LLM sont puissants pour le prototypage et l’automatisation, mais ne remplacent pas les fondamentaux du développement logiciel, comme une conception réfléchie, la revue et le partage du contexte
Le véritable goulot d’étranglement de l’écriture de code
- Depuis des années, l’écriture de code en elle-même n’est pas le goulot d’étranglement de l’ingénierie logicielle
- Les vrais goulots se situent dans la revue de code, la transmission des connaissances via le mentorat et le pair programming, les tests, le débogage, ainsi que le coût de la collaboration et de la communication
- La gestion des tickets, les réunions de planification, les rituels agiles et d’autres प्रक्रियures complexes ralentissent encore davantage le rythme
- Tous ces processus nécessaires pour garantir la qualité demandent en réalité bien plus de temps et de réflexion que l’écriture de code elle-même
- Pourtant, grâce aux LLM, le coût de génération de code fonctionnel tend vers zéro
- Mais le coût de la compréhension du code, des tests et de l’établissement de la confiance devient au contraire plus élevé
- La vitesse d’implémentation initiale a augmenté, mais davantage de code doit désormais être revu, intégré et maintenu, ce qui alourdit la charge
Les LLM changent la nature du travail — ils ne la suppriment pas
- Des outils LLM comme Claude accélèrent l’implémentation initiale, mais comme davantage de code entre dans le système en moins de temps, ils imposent finalement une charge plus lourde aux personnes en charge de la revue et de la maintenance
- Cette charge s’aggrave particulièrement dans les situations suivantes
- il n’est pas certain que l’auteur comprenne réellement le code qu’il a soumis
- le code généré utilise des patterns peu familiers ou enfreint les conventions existantes
- les cas limites et les effets de bord involontaires ne sont pas clairement visibles
- En conséquence, même si produire du code devient plus facile, la difficulté de validation augmente, et la vitesse globale de l’équipe ne s’améliore pas réellement
- Les développeurs plaisantaient déjà autrefois sur le « copier-coller engineering », mais avec les LLM, ce phénomène s’est fortement amplifié
La vraie difficulté, c’est comprendre le code
> « Le principal coût du code n’est pas son écriture, mais sa compréhension »
- Grâce aux LLM, la production de code s’accélère, mais raisonner sur son fonctionnement, détecter des bugs subtils ou garantir sa maintenabilité à long terme ne devient en rien plus facile
- C’est encore plus difficile lorsque le reviewer ne peut pas distinguer le code généré du code écrit directement, ou lorsqu’il est compliqué de comprendre pourquoi une solution donnée a été choisie
Les équipes dépendent toujours de la confiance et d’un contexte partagé
- Le développement logiciel repose fondamentalement sur la collaboration et dépend entièrement d’une compréhension partagée, de l’alignement et du mentorat
- Lorsque le code est généré plus vite qu’il ne peut être discuté et revu, l’équipe peut avoir l’illusion que la qualité a déjà été validée, alors qu’en réalité elle ne l’a pas été
- Cela accroît la charge psychologique des reviewers et des mentors, ce qui peut ralentir l’équipe entière d’une nouvelle manière
Les LLM sont puissants, mais ne résolvent pas le problème de fond
- Les LLM ont une grande valeur pour le prototypage rapide, le scaffold et l’automatisation, mais ils ne suppriment pas le besoin de clarté de pensée, de revue attentive et de conception approfondie
- Le coût d’écriture du code a baissé, mais le coût pour une équipe de comprendre ensemble le code et de lui donner du sens ne change pas
- Le vrai goulot d’étranglement reste toujours la « compréhension et la collaboration »
7 commentaires
Je suis exactement le type de développeur présenté dans cet article : il me manque des compétences techniques et je dépends fortement des LLM.
Comme mes connaissances techniques sont insuffisantes, il m’est difficile d’avancer sur mes tâches en respectant le WBS sans IA…
Cela dit, que puis-je faire pour réduire au moins le temps que mes développeurs seniors passent à relire mon code ?
Et au passage, ce serait bien si cela me permettait aussi d’enrichir mes connaissances…
Pour réduire le temps de review, il faut être capable de décider soi-même et d’expliquer dans quel contexte le code que l’on a écrit est né, ainsi que pourquoi on a choisi cette option parmi différentes méthodes d’implémentation. Pour y parvenir, il faut pratiquer régulièrement le point 3., le week-end ou pendant son temps libre, et il est aussi utile de parcourir au hasard des bibliothèques connues ou du code publié par d’autres sur GitHub afin d’analyser des éléments comme la structure du code et le style d’implémentation.
Merci beaucoup pour ces gentils mots !!
Et pourtant, quand on voit qu’ils réduisent les effectifs, c’est franchement désespérant… Comment voulez-vous que 4 personnes gèrent 12 projets ? Et en plus, l’une d’elles doit aussi faire de la gestion…
T_T Vous devez vraiment traverser une période difficile.
Avis Hacker News
En tant que mentor expérimenté, j’ai vu des stagiaires ambitieux mais encore peu aguerris produire en une journée l’équivalent d’une à deux semaines de code. Mais mon travail est en fait devenu plus difficile qu’avant. Lors des revues de code, les stagiaires n’ont pas suffisamment réfléchi en profondeur au code qu’ils ont écrit, si bien que mes retours passent mal. Les bugs simples ou les petits problèmes ont presque disparu, mais les problèmes restants sont plus subtils et complexes, et bien plus difficiles à expliquer. En plus, de nouveaux types de bugs apparaissent, que je n’avais jamais vus auparavant. Du code qui a l’air correct ne fonctionne en réalité pas du tout, et ce qui semble abouti est souvent cassé dès les bases. Les juniors qui collaborent avec des LLM ont plutôt tendance à livrer d’un coup un code complexe, qui paraît terminé mais crée des problèmes de collaboration et de maintenance sous plusieurs angles, plutôt qu’un code simple qui mérite discussion. Au final, la méthode traditionnelle d’« amélioration progressive » pour amener une PR jusqu’à un bon niveau de qualité ne semble plus vraiment fonctionner. Quand on donne du feedback, au lieu de corriger la PR d’origine, ils proposent parfois une approche entièrement nouvelle — qui crée souvent encore d’autres problèmes. Résultat, les seniors passent bien plus de temps qu’eux sur une seule PR. Côté junior, ils ont peut-être l’impression d’être très productifs, mais on voit aussi les retours des reviewers seniors devenir moins chaleureux ou encourageants qu’avant. Au bout du compte, imposer beaucoup de cas de test a été ce qui a le mieux marché, mais même ces tests atteignent leurs limites à cause de problèmes similaires
En voyant ce genre de code « qui a l’air fini mais ne marche pas du tout », ça m’a rappelé un projet offshore de développement logiciel à 250 000 dollars que j’avais connu autrefois. Sur le papier, tout semblait conforme à la spécification, mais dans la pratique c’était un système totalement incohérent. L’équipe s’était tellement focalisée sur l’interprétation de la spec qu’elle avait laissé de côté les évidences de bon sens, et on avait fini par jeter tout le projet à la poubelle immédiatement. Ce qui me frappe, c’est que ce genre de situation est maintenant automatisé et gratuit grâce aux LLM
Je me reconnais complètement dans ce problème. D’après mon expérience personnelle, les LLM permettent certes de produire très vite des milliers de lignes de code, mais le vrai travail difficile reste la revue de code, la correction des bugs, la vérification des vulnérabilités de sécurité, le refactoring, la suppression du code inutile, etc. Au final, il m’est souvent arrivé d’être plus productif en codant moi-même. L’usage le plus réaliste des LLM, c’est l’autocomplétion ou la génération de petits morceaux simples. Si un junior s’intercale avec un LLM et que je dois moi aussi faire la transmission derrière, l’efficacité baisse encore plus. Ceux qui ont aujourd’hui l’impression d’être plus productifs avec les LLM ont peut-être simplement sauté ces tâches importantes, ou n’y prêtent pas du tout attention. En pratique, seule une petite minorité qui se soucie réellement de la qualité du produit se retrouve à absorber l’énorme volume de code. On les prend parfois pour des gens inutilement tatillons, alors qu’en réalité ce sont les vrais héros qui veulent livrer le meilleur produit possible aux utilisateurs. Je ne vois pas vraiment de solution, et la situation risque plutôt d’empirer. Des développeurs formés uniquement avec des LLM vont continuer à arriver dans l’industrie, tandis que les entreprises qui fabriquent ces outils continueront leur marketing exagéré. Au final, le fardeau du maintien de la qualité ne fait qu’augmenter
Je vis moi aussi ce phénomène d’« effort inversion », où les seniors investissent plus d’efforts sur une PR que les juniors. Dans mon cas, des rédacteurs RP utilisent l’IA pour écrire des billets de blog ou des communiqués de presse, et quand moi, expert du sujet, je reçois le résultat, mon temps de travail triple ou quadruple à force de corriger toutes les hallucinations et erreurs de l’IA. Leur rôle était censé me soutenir, mais maintenant c’est moi qui dois les aider. Et comme les hallucinations changent à chaque fois, il faut recommencer depuis zéro à chaque nouvelle livraison. J’en ai déjà parlé aux dirigeants, et à ce rythme, la moitié des effectifs RP auront probablement disparu l’an prochain. Si leur rôle consiste juste à copier un email dans ChatGPT avant de me le renvoyer, alors je peux le faire moi-même
J’aimerais bien avoir plus de détails sur le passage « pendant la revue, mes retours n’ont pas été bien compris ». Je rencontre un problème similaire, donc si tu as une solution ou un éclairage, je suis preneur
Pour compléter ma pensée, la génération précédente a naturellement acquis une compréhension profonde de la structure et de la conception logicielle via le refactoring et les tests unitaires. Mais si demain les LLM génèrent aussi les tests unitaires, les développeurs risquent de perdre des occasions d’auto-réflexion et d’apprentissage, comme se demander « de quoi ai-je vraiment besoin ? » ou « comment faire ça plus simplement ? ». Pour moi, c’est précisément là que se joue la différence entre un « développeur », un « ingénieur » et un « architecte ». Les LLM ou le « vibe coding » ne développent jamais ce type d’état d’esprit. Dans un langage comme Go, où la syntaxe pèse moins, ce genre d’erreurs de conception ressort plus facilement en revue. La structure des tests unitaires en Go est utile pour diagnostiquer la complexité du code. En fin de compte, il nous faut de meilleures méthodes de test et de revue. Le fuzz testing, les tests unitaires et les tests d’intégration ne suffisent pas. Je pense qu’il faut un framework de test automatisé capable de vérifier logiquement si les branches du code sont bien appelées et si les conditions de satisfaction sont réellement remplies
Grâce aux LLM, le coût d’introduction d’un nouveau logiciel tend vers presque zéro, mais le coût pour comprendre ce code en profondeur, le tester et lui faire confiance me semble plus élevé que jamais. Cela dit, d’après mon expérience, je ne pense pas que le code produit par les LLM soit tellement pire que beaucoup de vieux morceaux de code hérités de quelqu’un qui est parti depuis longtemps et à qui on ne peut même plus poser de questions, ou que du code qui traîne partout en ligne. Au contraire, un LLM n’est pas réticent à écrire des tests comme un humain, et il ne se laisse pas non plus aller par fatigue. Ma philosophie part du principe que « tout code est une dette potentielle ». Donc je m’inquiète assez peu du niveau de confiance qu’on peut lui accorder. J’ai effectivement construit avec l’IA de très grosses codebases qui fonctionnaient correctement — à condition que le domaine soit vérifiable, avec beaucoup de tests et d’itérations. En conclusion, les LLM ont accéléré la production de code, mais ils ont aussi réduit la stimulation intellectuelle du codage lui-même, au point de me donner l’impression que mon cerveau devient lui aussi plus paresseux. On entre plutôt dans une époque où le vrai travail intellectuel en amont — définition des besoins, conception, etc. — devient bien plus important
Même sans LLM, l’industrie n’était déjà pas limitée par un « manque de code », mais par la demande du marché et les limites du capital, qui plafonnaient la vitesse de développement. Les outils sont devenus tellement bons que le codage en lui-même n’est plus le cœur du problème. Le contexte n’a plus rien à voir avec les débuts. Je repense à cette anecdote de l’époque où Bill Gates était adolescent, quand le simple fait de « savoir coder » était en soi une ressource rare. Une entreprise, pressée, avait embauché Gates à 16 ans avec Paul Allen, et trouvait extraordinaire qu’ils puissent simplement écrire du code rapidement. Aujourd’hui, la vraie question est plutôt : « Qu’est-ce qu’on développe, et y a-t-il un modèle économique derrière ? »
Vidéo liée
Je suis d’accord avec l’idée que le code n’était pas le goulet d’étranglement, à cause de la demande du marché. Avant le boom de l’IA, Marc Andreessen disait déjà : « le capital est abondant, mais les bonnes idées d’investissement manquent ». Je ne pense pas que cette phrase reflète parfaitement la réalité, mais au moins, dans les données, sa déclaration semble crédible
Comme dans l’ancienne anecdote sur Bill Gates, la capacité à écrire du code de haute qualité et à le comprendre en profondeur reste une ressource rare. La différence, c’est qu’aujourd’hui l’industrie ne semble plus vraiment valoriser cette capacité
Du point de vue de l’analyse d’impact de l’IA, nous avons tendance à surestimer l’efficacité. Mais l’économie réelle crée des goulets d’étranglement dans des structures bien plus complexes que cela. Même si la production de code est multipliée par 100, rien ne garantit que cela ait une utilité concrète
Quand je lis ce genre de témoignage ces jours-ci, je trouve ça très déprimant. Si un junior livre un énorme bloc de code qui ne fonctionne pas, qu’il n’a ni testé ni vérifié lui-même, qu’il n’a pas cherché à simplifier, et qu’il transmet sans documentation, sans commentaires et sans explications, alors c’est déjà en soi ce qu’on pourrait appeler une « version du LLM installée dans un humain ». Au fond, ce qui compte, c’est l’esprit critique et le sens de la responsabilité vis-à-vis du résultat. J’ai même l’impression qu’un LLM a plus de chances de réagir fidèlement à du feedback qu’un junior software engineer classique
Moi aussi, à une époque, je pensais que l’écriture du code était le goulet d’étranglement, mais en dix ans j’ai compris que la vraie difficulté était d’aligner la technologie avec le business. Même dans des environnements B2B ou SaaS remplis de tas de code complexes et différents selon les clients, si la technologie est bien alignée sur le business, tout se passe bien. Aujourd’hui, la technologie a suffisamment progressé : le vrai enjeu, c’est désormais l’ego du développeur et sa capacité à se concentrer sur la valeur client. Il faut se demander ce que veulent réellement les clients, s’ils paieront pour cela, et même s’il faut une interface web tout court. Les « fonctionnalités jouet pour chat » que les développeurs créent pour leur propre satisfaction sont la vraie cause de l’augmentation des coûts cloud. Le plus triste, c’est que même avec des incitations agressives, des stock-options ou des salaires élevés, on ne résout pas ce problème de fond. Il faut qu’au moins une personne ait une véritable vocation à bien construire le logiciel, et la volonté d’aller parler directement aux clients pour faire les choses correctement
Le moment où les LLM m’ont vraiment aidé dans une organisation, c’était sur mes projets personnels ou secondaires. Quand on développe une application pour résoudre un petit problème, le temps manque et l’écriture du code devient réellement un gros goulet d’étranglement. Dans ce type de projet, mon usage des LLM est de 100 %
Je suis d’accord à 100 %. Si j’investis 1 à 2 heures par jour dans Claude code, j’ai souvent quelque chose d’utilisable à la fin du week-end. Avec un faible investissement en temps, il devient facile de valider une idée ou de faire une expérimentation. Ce type d’outil LLM crée aussi énormément de valeur dans les organisations pros. On peut prototyper très vite toutes sortes d’outils internes ou de systèmes d’automatisation qu’on n’aurait pas eu le temps de construire autrement. Si un collègue a besoin d’une requête DB ou d’une petite automatisation, il peut demander à Claude, relire, puis copier-coller directement. C’est aussi l’objectif de mon projet mcp-front[0] : aider des personnes qui ne sont pas ingénieurs à traiter elles-mêmes les tâches répétitives de leur domaine
GitHub de mcp-front
Honnêtement, à ce stade de ma carrière, il m’est difficile de consacrer des semaines entières à quelque chose, et avec l’expérience je garde toujours en tête les exigences non fonctionnelles et la perspective long terme. Même si je saute les tests, j’ai quand même encore énormément de choses à réfléchir derrière
La célèbre phrase de Robert C. Martin me revient en tête : « on passe plus de 10 fois plus de temps à lire du code qu’à en écrire »
Citation liée
Malheureusement, son style Clean Code peut aussi, dans la pratique, fragmenter le contexte et rendre l’intention encore plus difficile à comprendre
Le pire, c’est qu’on peut réduire le temps d’écriture tout en augmentant le temps de lecture, si bien que la charge totale de travail ne baisse pas forcément
Puisque personne ne l’a mentionné, je partage ce billet de Joel Spolsky du 2 octobre 2000
Joel on Software: Painless Functional Specifications (2000)
Le vrai goulet d’étranglement, ce n’est pas le code mais la spécification fonctionnelle. Définir clairement comment le logiciel doit fonctionner, en anglais, avec des diagrammes, des user stories, etc., est plus important. Si la spec est bien cadrée, un LLM peut très bien produire d’un coup une solution, des tests et des tests d’intégration excellents. Si c’est trop volumineux, la spec ne doit pas être gérée dans un seul fichier Markdown, mais découpée par fonctionnalité comme un wiki, avec des liens et des références. Le vrai avantage compétitif ne vient pas de la difficulté d’implémentation, mais de l’énergie investie dans la spécification
L’auteur de ce commentaire n’est pas d’accord avec la thèse de l’article. Peut-être que dans une grande entreprise, le code n’est pas le goulet d’étranglement, mais du point de vue d’une startup, les ressources sont limitées et un planning efficace est encore plus important. Autrement dit, dans bien des cas, produire du code qui fonctionne réellement était bel et bien le principal goulet d’étranglement. Au final, on ne peut pas généraliser la question de « l’utilité de l’IA/LLM ». Pour certaines équipes, le code était le goulet d’étranglement ; pour d’autres, non
Comme tout le monde le sait, le code généré par les LLM est souvent mauvais, voire impossible à relire. Quand un junior soumet du code LLM étrange et qu’on lui demande pourquoi, il ne sait pas répondre et dit simplement que le LLM l’a généré. Au final, cette tendance ne fait qu’ajouter du « bruit » et de l’overhead à la maintenance du code. Si l’on ne peut pas éviter d’introduire des LLM, alors il faudra bien confier aussi aux LLM la revue et la maintenance. Bien sûr, le résultat sera un spaghetti encore plus complexe. Mais dans la réalité, pour la plupart des business, la qualité n’a souvent pas tant d’importance que ça : si le code LLM fonctionne à peu près, cela suffit. Ou bien il suffit d’empiler encore plus de LLM jusqu’à ce que le problème soit résolu au niveau nécessaire