L’IA ne rendra probablement pas vos processus plus rapides
(frederickvanbrabant.com)- Des attentes irréalistes autour de l’IA se diffusent dans la vague d’optimisation des processus, mais le simple fait d’introduire de l’IA n’améliore pas automatiquement la vitesse d’exécution
- La vraie raison pour laquelle le développement logiciel prend du temps n’est pas la vitesse de codage, mais le processus qui consiste à transformer des exigences floues en une définition claire du problème
- La génération de code par IA se heurte aux mêmes problèmes en amont, et une implication profonde d’experts du domaine et du produit est indispensable pour obtenir des résultats précis
- Dans les comparaisons de cas d’usage de l’IA, le processus d’accompagnement (handholding) souvent omis est ce qui crée réellement l’écart de productivité, et des développeurs humains verraient eux aussi leur productivité bondir s’ils recevaient la même documentation détaillée
- Pour vraiment accélérer un processus, la priorité est, comme l’enseigne The Goal, de « fournir au goulot d’étranglement des entrées prévisibles et de haute qualité »
Optimisation des processus et attentes autour de l’IA en période de ralentissement du marché
- Quand le marché ralentit, la plupart des organisations ont tendance à se concentrer, au moins en partie, sur l’optimisation des processus ; récemment, un facteur supplémentaire s’y est ajouté : l’IA, accompagnée d’attentes irréalistes
- The Toyota Way et The Goal rappellent qu’il est facile de mal comprendre ce sur quoi beaucoup d’initiatives d’optimisation des processus devraient réellement se concentrer
- Une étape qui prend longtemps peut être un signal indiquant où commencer à améliorer, mais cela ne signifie pas forcément que le problème naît réellement à cet endroit
- Si l’on se contente d’ajouter des personnes ou d’espérer que l’IA augmentera fortement la vitesse, on ne voit pas pourquoi le travail prend du retard
- Pour accélérer un processus, il faut d’abord vérifier si les exécutants disposent réellement des entrées et des conditions nécessaires pour commencer et terminer le travail
Le goulot d’étranglement visuel
- Un exemple de diagramme de Gantt permet de voir visuellement que l’étape la plus longue est le développement logiciel
- En principe, on utiliserait plutôt du BPMN, mais ici un diagramme de Gantt est présenté pour faciliter l’explication
- Si l’objectif est d’améliorer le throughput d’un projet, il est logique de commencer par examiner l’étape la plus longue
- Le problème tient à la manière dont les gens essaient de le résoudre
- Ajouter plus de personnel au problème (throw people at the problem)
- Supposer que l’IA le fera beaucoup plus vite
- On n’examine pas vraiment « pourquoi cette étape prend-elle autant de temps ? », et surtout, le fait qu’une étape soit longue ne signifie pas que la cause du problème se trouve dans cette étape
Résoudre le problème en amont
- L’exemple prend le développement logiciel, mais cela s’applique de la même manière à tout processus qui prend plus de temps que souhaité
- Le développement logiciel ne devient pas plus rapide simplement en augmentant la vitesse de frappe ; sinon, tout le monde suivrait des cours de dactylographie
- L’essence du développement logiciel est de traduire un problème en une solution que l’ordinateur peut résoudre automatiquement, de préférence de manière sûre et évolutive
- Cela exige une compréhension globale du problème
- Dans une approche proche du waterfall, il faut des documents fonctionnels ou de cadrage
- Dans une approche agile, il faut des itérations continues avec des experts métier
- Ce qui ralentit réellement le développement, c’est le processus consistant à comprendre ce que veut dire une demande de feature ambiguë qui n’a qu’un titre
- Même la demande « send mail to user once sale is completed » n’est pas une exigence directement implémentable
- On peut envoyer un mail, mais que doit-il contenir ?
- S’il y a eu un problème dans le processus de vente, faut-il envoyer un mail d’erreur ?
- À quel moment la vente est-elle considérée comme « terminée » ?
L’argument selon lequel il suffit de tout confier à l’IA
- Un argument souvent entendu est que la génération de code par IA permettrait de contourner l’étape de développement, les développeurs devenant essentiellement des chefs de projet
- Beaucoup imaginent que la longue phase actuelle de développement logiciel sera remplacée par une phase de développement par IA d’environ trois jours
- Il existe une image du résultat attendu de ce développement par IA, mais dans la réalité cela ne fonctionne pas ainsi : on se heurte exactement aux mêmes problèmes en amont
- Il est vrai que l’IA peut générer du code rapidement (qu’il s’agisse ou non d’une bonne chose est un autre débat), mais génération rapide ne veut pas dire génération correcte
- Ce qui est systématiquement ignoré dans les comparaisons entre développement humain et développement par IA, c’est le processus d’accompagnement (handholding) nécessaire pour que l’IA fonctionne correctement
- Cette approche peut être plus rapide que la méthode classique, mais la comparaison n’est pas équitable
- Pour que le développement par IA fonctionne, il faut une implication bien plus forte des experts métier et des experts produit
- Il faut décrire chaque fonctionnalité jusqu’au moindre détail
- Chaque correction de bug doit elle aussi détailler précisément le résultat attendu
- C’est exactement ce que les développeurs logiciels demandent depuis le début de leur métier : une vue d’ensemble détaillée du problème et du résultat final attendu
- Si l’on fournissait aux développeurs humains le même volume de documents de feature/scope, leur productivité augmenterait elle aussi fortement
Comment augmenter réellement la vitesse d’un processus
- Pour accélérer un processus, il faut s’assurer que les personnes chargées du travail disposent réellement de tous les moyens nécessaires pour l’exécuter
- Si un processus d’approbation juridique est lent, il faut d’abord examiner ce qui est nécessaire pour lancer ce processus d’approbation
- Si l’on doit courir après cinq personnes à cause de documents incomplets, ajouter davantage de juristes au service ne rendra pas le processus plus rapide
- L’un des grands enseignements de The Goal est qu’un goulot d’étranglement doit recevoir des entrées prévisibles et de haute qualité
- "bottlenecks should receive predictable, high-quality inputs"
- Le premier point de départ de l’automatisation des processus ne devrait pas être le goulot d’étranglement lui-même, mais l’amélioration de la qualité des entrées qu’il reçoit et de leur prévisibilité
1 commentaires
Avis sur Hacker News
On dit parfois que ce que le développement logiciel a toujours voulu depuis le début, c’est « qu’on lui décrive en détail le problème et le résultat souhaité », mais en réalité c’est précisément ça, le software engineering
Il faut abandonner l’idée qu’en 2026, avec des exigences et des spécifications suffisamment détaillées, on pourra produire une solution parfaite du premier coup
D’après mon expérience, grâce à l’IA, on peut itérer bien plus vite sur des fonctionnalités ou des idées, et désormais les frictions viennent surtout de l’alignement et de la coordination avec les autres équipes
Pour accélérer le processus, il faut selon moi réduire les coûts de coordination et donner davantage de pouvoir de décision et d’exécution aux individus et aux équipes
Même Anthropic, avec une spécification parfaite, une implémentation de référence et des milliers de tests écrits par des humains pendant des années, n’a pas réussi à produire quelque chose d’aussi simple qu’un compilateur C fonctionnel
Les modèles actuels ne sont pas encore assez bons pour produire un logiciel d’exploitation non trivial sous supervision minimale d’une personne soigneuse, même avec une spécification parfaite et des tests parfaits
Sans spécification parfaite et sans batterie de tests parfaite écrite à la main, c’est encore plus difficile, et ce sera peut-être possible vers 2027
Je reçois souvent l’après-midi des demandes imaginées par le responsable produit, et ils ne pensent qu’au chemin nominal, parfois même à une partie seulement de celui-ci
Comme nous sommes une entreprise mondiale, nous devons respecter les réglementations et les lois de chaque pays ; après avoir implémenté une fonctionnalité, on nous dit parfois : « en fait, dans 90 % des marchés où nous opérons, on n’a pas le droit légal de faire ça », et il faut alors rajouter une fonction de désactivation
Ensuite, on revient nous voir avec : « dans certains de ces marchés, c’est possible si on suit une procédure réglementaire, donc merci de l’implémenter ainsi »
Comme l’échéance est imminente, on finit par bricoler la solution
Ce n’est pas du software engineering, et ça n’a même rien à voir avec le logiciel lui-même
Le travail d’un ingénieur logiciel, c’est de recevoir une liste d’exigences et de trouver comment les satisfaire ; la collecte des exigences n’est pas un problème de software engineering
Le logiciel, c’est l’implémentation, et le produit, c’est le comportement ; le comportement de ce qu’on veut construire doit être connu avant de commencer sérieusement à le construire
Si quelqu’un avait simplement repoussé d’une semaine pour faire une vraie analyse, on aurait pu concevoir une structure scalable, facile à étendre, facile à maintenir et bien plus confortable pour l’avenir
Cela fait plus de 40 ans que j’ai écrit mon premier programme, et je n’ai jamais vu un cas où l’on finalise d’abord la spécification, puis on écrit le logiciel, et où tout se passe bien
Dans toute ingénierie un tant soit peu non triviale, la partie la plus difficile, c’est de comprendre le problème, et les premières versions du logiciel servent justement à arriver à cette compréhension
C’est pourquoi je pense que les « usines à logiciel » basées sur l’IA ne fonctionneront jamais vraiment
Au final, on retombe dans le cycle en V, avec des architectes qui dessinent des diagrammes UML et transmettent à une équipe de programmeurs un travail d’implémentation en apparence simple, mais qui revient en fait à implémenter la mauvaise chose
L’IA est en revanche très bonne pour passer rapidement d’une première version erronée à une deuxième version un peu moins erronée
Il ne faut simplement pas oublier que la mission centrale reste de comprendre le problème qu’on essaie de résoudre
Si on me donne seulement des spécifications détaillées, je ne suis plus qu’un robot codeur, et ce genre de travail, je le laisse aux juniors
Comme avant, mon travail consiste à lire ces exigences, les comprendre et les valider à l’aune de la réalité que je connais
C’est pareil pour le code
Depuis au moins 20 ans, le cœur du software engineering, c’est ne faire confiance à personne ; cela n’a pas changé, et ça demande toujours énormément de temps et d’efforts
Quand les LLM sont apparus, on aurait dit que les gens pensaient qu’il suffisait de dire « crée-moi un clone de Facebook »
On se rend compte maintenant qu’il faut écrire des exigences plus précises et mieux définies
Cela a toujours été le goulot d’étranglement du logiciel
À une époque, je recevais réellement des demandes du type « récupère les données et donne-les à l’utilisateur »
Rien n’était défini : quelles données, où elles étaient stockées, dans quel format elles devaient être renvoyées ; il fallait donc passer beaucoup de temps avec le produit pour comprendre ce qu’ils voulaient vraiment
Avec les LLM, il faut faire quelque chose de similaire pour obtenir de bons résultats, et des exigences ambiguës produisent des résultats ambigus
Ils remplissent des modèles avec la nature du problème et son origine, par exemple en précisant qu’un champ X existe dans le backend mais pas dans le frontend, puis indiquent où récupérer les données, comment les récupérer et quels sont les critères d’acceptation
C’est le genre de chose qu’ils ne faisaient pas avant, par paresse ou parce qu’ils se disaient « les devs se débrouilleront »
Ensuite, le développeur peut copier-coller le contenu de ce ticket Jira dans l’agent LLM de son choix, ou laisser le LLM le lire automatiquement via Atlassian MCP
Ça a beaucoup aidé les développeurs, et les exigences sont devenues très claires
Honnêtement, rien qu’à cette première étape, on a l’impression que les PM sont déjà à mi-chemin de l’implémentation d’une fonctionnalité ; à l’avenir, on pourrait même imaginer qu’ils fassent tout eux-mêmes, avec quelques développeurs restant plutôt comme des SDET que comme des implémenteurs à part entière
Il y décrit avec précision les caractéristiques essentielles du vibe coding et l’expérience que nous vivons aujourd’hui
Après des succès initiaux dans quelques domaines soigneusement choisis, on obtient en s’étendant hors de ces domaines des gains de productivité raisonnables, mais pas révolutionnaires
https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.p...
Je n’ai jamais essayé d’utiliser un prompt du type « crée-moi un clone de Facebook » ; j’explique plutôt comment le système doit fonctionner
Par exemple, j’ai demandé un script Python qui lise
/etc/hosts, cherche certaines valeurs d’hôte définies dans un.conf, attribue un nom à chaque configuration, détecte l’environnement courant, crée une icône en haut à droite du GNOME par défaut d’Ubuntu 22, et, au clic, liste les noms des configurations puis, lors d’une sélection, sauvegarde/etc/hostsavant de ne modifier que les lignes des noms d’hôte concernésJ’ai ainsi obtenu presque du premier coup un simple sélecteur d’environnement sous forme d’indicateur d’application GNOME, qui fonctionnait pour l’essentiel après avoir corrigé quelques lignes
Si on donne une vraie spécification à un LLM, il produit quelque chose de correct ; il comprend même quand on invente un faux DSL pour décrire ce qu’on veut
Si l’ancien processus ne fonctionnait pas, c’est parce que les auteurs des exigences ne comprenaient pas l’intention métier ou étaient négligents, et produisaient donc des exigences ambiguës ou mauvaises
Le LLM ne fait que rendre ces mêmes exigences ambiguës ou mauvaises plus plausibles en apparence, mais dès qu’on creuse, les problèmes apparaissent
On pose des questions comme : « qu’est-ce que “récupérer les données” veut dire exactement ? »
Le LLM, lui, répond juste : « bien sûr ! voici le code complet qui récupère les données et les donne à l’utilisateur », puis passe à autre chose
Cet article suppose que l’IA n’influence que l’étape de développement, mais ce n’est clairement pas vrai
Elle peut accélérer toutes les étapes, y compris l’idéation, le juridique, la documentation, le développement et le déploiement
Pour l’idéation, on peut échanger des idées, les confronter à une base de connaissances et produire des documents de conception ; pour la documentation, on peut générer de larges portions des docs
Pour le développement, évidemment, et pour le déploiement, on peut produire des manifestes de déploiement, des outils de test et des éléments de connaissance sur les plateformes cloud
Toutes les étapes peuvent devenir meilleures et plus rapides avec l’IA ; pas intégralement, mais en grande partie
C’est pareil pour le développement : il y a la partie qui consiste à mieux comprendre le problème que tout le monde et à concevoir la solution, mais aussi une part de pur travail ingrat
Si l’on sait qu’un bouton doit faire X, alors concevoir ce bouton, le placer, penser aux états hover et press ainsi qu’aux exceptions, puis le relier au backend, relève du travail ingrat qu’on peut éviter, et ce principe vaut à presque toutes les étapes
Quand on veut ajouter une nouvelle fonctionnalité importante, il faut souvent passer des jours, des semaines ou des mois en réunion avec les équipes métier pour comprendre comment le travail circule entre les systèmes X, Y et Z, ainsi que les exceptions importantes
Par exemple, le sous-ensemble A est traité comme ceci, B comme cela, mais à la dernière étape on fusionne les deux groupes, sauf que C nécessite un processus spécial 97
À partir de cette compréhension vient ensuite la conception d’une solution système couvrant plusieurs systèmes, avec un mélange de systèmes internes et de systèmes fournisseurs, chacun ayant ses propres limites de personnalisation, ce qui pousse la forme finale de la solution dans plusieurs directions
Il y a évidemment de la valeur à accélérer le codage, mais ce n’est qu’une pièce du puzzle, et les LLM actuels n’aident pas à collecter l’information métier ni à définir la solution
Il y a même un autre aspect : davantage de personnes occupant des rôles variés peuvent désormais créer des outils logiciels pour résoudre des problèmes qu’on traitait auparavant à la force des procédures manuelles
Nous sommes un petit industriel, donc pas dans des projets géants d’entreprise exigeant une profonde expérience en software engineering, mais de simples outils logiciels améliorent un peu partout les processus et la productivité
Quand une responsable des expéditions peut résoudre avec un outil sur mesure un problème qui lui coûtait auparavant un grand nombre d’heures de travail, c’est vraiment impressionnant
Nous utilisons beaucoup l’IA pour le développement logiciel, mais nous ne livrons pas plus vite ; j’ai même l’impression que c’est plus lent, pour des raisons similaires ou différentes
Il y a cette étrange sensation d’attendre une utopie qui n’arrive jamais, sans même réussir à pointer précisément où ça bloque
Au contraire, ces désaccords et cette défiance créent des opportunités et points d’émergence sur le marché
Si le QI moyen des participants d’un projet est de 140, alors une IA à 150 de QI peut reproduire chacun des individus du pipeline
Ceux qui disent que l’IA ne peut pas faire ceci ou cela doivent accepter que cet écart de QI augmente de façon monotone
D’un côté, cet article est un texte clair qui décrit exactement ce que pensent et observent sur le terrain beaucoup de personnes faisant du travail technique dans de grandes organisations
Je suis d’accord à 110 % avec l’auteur, et j’aimerais que d’autres comprennent aussi ce qu’il dit
D’un autre côté, sur HN comme au travail, j’ai l’impression d’avoir eu cette discussion des dizaines de fois récemment
Les dirigeants ont des incitations sociales et financières à faire comme si l’IA allait vraiment accélérer les choses, donc un simple billet de blog ne les convaincra pas
À ce stade, il ne reste plus qu’à attendre que leurs projets IA échouent ou avancent aussi lentement que les projets existants, en espérant qu’ils en tirent quelque chose
J’hésite même à partager ce genre d’article dans l’entreprise, car on a l’impression que tout ce qui ne va pas dans le sens du statu quo est mal reçu
Les visuels et les diagrammes de Gantt sont précisément le langage PM que les PM peuvent comprendre
Tant que les dirigeants et les investisseurs continueront à envoyer des signaux en faveur de “l’innovation”, ça ne se réglera pas tout de suite, mais ce genre de chose ne peut pas durer éternellement non plus
En ce moment, je passe mon temps à jardiner et à m’obséder sur des projets personnels de code avec des outils agentiques
Je construis par exemple une base de données OLTP haute performance depuis zéro, un nouvel environnement de programmation persistant logique-relationnel, des synthétiseurs originaux fondés sur des mathématiques inhabituelles, ou encore des soft processors sur FPGA
Bref, des activités parfaitement ordinaires
Donc je sais ce que ces outils peuvent faire quand ils sont entre les mains d’une seule personne, et c’est réellement impressionnant
Mais quand j’entends des amis en entreprise me parler de quotas minimaux de tokens, de classements de “star AI coders”, ou de consignes comme « ne faites pas de code review » ou « ne codez pas à la main », ça me fait secouer la tête
J’ai pris un peu de travail en contrat cet hiver, c’était correct, mais pendant que le fondateur vibe-codait un nouveau projet complet chaque week-end, les code reviews ont dégénéré en duels entre LLM
Ces outils ne sont pas très bons pour le travail d’équipe ni pour le vrai software engineering en équipe
Je vais simplement me mettre en retrait et observer jusqu’à ce que le secteur fasse un peu de ménage
Les seuls endroits où il fera bon travailler seront probablement ceux qui savent dire « vas-y doucement ! », et qui ont encore des anciens assez sages pour pouvoir dire ça et être entendus
En attendant, je vends des bottes de rhubarbe fraîchement coupée, 5 dollars, dans la région de Hamilton en Ontario
J’ai aussi des asperges, beaucoup d’asperges
Il y a une dualité intéressante
Sur ce que je sais déjà bien faire, les LLM ont relativement peu d’impact ; en revanche, sur ce que je ne sais pas faire, c’est un changement énorme
Les grandes entreprises peuvent recruter la plupart des rôles nécessaires à un projet, donc l’effet global y sera relativement limité
Au mieux, on pourra faire accomplir approximativement à une personne le travail de cinq, réduire les coûts salariaux, et obtenir en échange un produit de moins bonne qualité
On devine facilement ce que donne cette combinaison de gains à court terme et de coûts à long terme
Mais pour les petits studios ou les développeurs indépendants, les LLM changent vraiment la donne
Faire approximativement le travail de cinq personnes, c’est un bond immense par rapport au fait de s’en passer, de dépendre d’assets tiers ou d’autres contenus, ou pire encore, d’improviser de manière catastrophique
Il suffit de regarder l’interface de presque tous les programmes manifestement agencés par un programmeur sans designer
Ou ceux qui essaient de copier quelque chose vu sur Dribbble sans avoir le niveau
Avec l’IA, soudain, on peut copier de manière plausible tout et tout le monde, et c’est d’ailleurs à peu près comme ça que fonctionne l’IA dans son ensemble
Ça ressemble à une définition de manuel
Personnellement, c’est exactement l’inverse
Les LLM ne m’aident que lorsque je sais déjà précisément ce que je fais
Les gens comprennent mal à quel point le développement logiciel non trivial est composé de bien moins de 50 % de codage
La phase de codage est généralement l’une des plus simples, et on la confie souvent à des développeurs juniors
Dans les grandes organisations, la plupart des changements de produit traversent plusieurs systèmes et plusieurs opérations humaines
Les profils senior et intermédiaires passent surtout leur temps à réaligner des priorités locales dans une entité cybernétique existante, puis à obtenir l’adhésion à cette nouvelle vision auprès d’autres équipes qui ont leurs propres priorités
Cela implique naturellement beaucoup de compromis et de politique
Les ingénieurs seniors se battent fermement pour éviter d’ajouter du « poids » aux systèmes dont ils sont responsables, et pour empêcher l’élargissement du périmètre ou les déviations par rapport à la direction qu’ils avaient l’intention de suivre
Il faut donc des compromis, ou bien une escalade vers le management pour arbitrer les priorités
Peut-être que l’IA pourra résoudre ça aussi, mais c’est une tâche bien plus difficile
Désormais, ce sont des appelleurs d’outils : les agents de codage peuvent lancer le lint, la vérification de types et les tests, corriger les erreurs remontées, explorer des plateformes d’observabilité comme Sentry pour trouver la cause racine, exécuter des benchmarks pour identifier le code lent ou les hot paths, et lire puis appliquer les documents de migration vers les nouvelles versions majeures des bibliothèques qu’ils utilisent afin de maintenir le système à jour
Si ces éléments ne sont pas structurés de manière à exercer une rétropression sur l’agent et à lui faire mieux comprendre le système, on reste au stade d’un simple rédacteur de code LLM un peu bête
Mais vu la vitesse à laquelle les modèles et leurs harnais progressent, il est clair qu’on peut aller bien plus loin
Cet article est globalement juste, et il donne des indices sur les points où concentrer l’IA si l’on veut réellement accélérer les processus
Par exemple, un chef de produit disait qu’il imagine un futur dans lequel une réunion avec les parties prenantes est considérée comme un échec si elle ne se termine pas avec un prototype interactif, et ça me semble aller dans la bonne direction
Une autre chose que j’anticipe, c’est que le vibe coding devienne un « Excel 2.0 »
Il permettra de construire des applications conversationnelles de manière largement self-service, et l’IT entrera alors dans une guerre permanente pour transformer cela en quelque chose doté de meilleures garanties de sécurité, de contrôles d’accès et de journaux appropriés, de scalabilité, de gestion du changement, etc.
Si l’on prend plus de recul historique, toute transition révolutionnaire commence par produire un cheval à vapeur
Lors de l’invention de la machine à vapeur, les gens imaginaient que le futur du transport serait une chose en forme de cheval, mue par la vapeur, tirant les chariots existants
Ce n’est que plus tard que nous avons compris qu’il fallait séparer la fonction du transport de sa forme
J’avais commencé à parler de cheval à vapeur à propos des MOOC, parce que les MOOC étaient une idée typique de cheval à vapeur
Il n’y a pas besoin de code pour faire un prototype
C’est comme dire qu’il faut forcément des acteurs et une caméra pour capturer une scène, alors que quelques croquis suffisent
Le Gantt présenté est un exemple de modèle en cascade, ou d’une autre méthodologie qui suppose qu’il existe une destination finale pour un logiciel
99,999 % des logiciels d’aujourd’hui ne sont pas développés ainsi
Le développement logiciel moderne n’a pas de destination finale
Toutes les deux semaines, le métier change ce que le logiciel est censé faire
De nouvelles fonctionnalités, de nouvelles intégrations, des fonctions modifiées, des composants mis à niveau ou remplacés, plus d’échelle, un autre hébergement : tout cela arrive en continu
Au bout de quelques années, le logiciel est fondamentalement transformé, et la qualité ainsi que les tests passent par la fenêtre
Ce n’est pas seulement une succession de rustines pour absorber les changements, c’est aussi une lutte constante et pénible contre l’entropie
Le logiciel devient un organisme vivant qui se blesse, change de mode de vie et vieillit
L’entreprise devient le gardien de cette créature, comme un soigneur de zoo essayant de maintenir en vie un animal dépressif
L’être humain est une créature d’habitudes, donc avec l’IA les mêmes problèmes se reproduiront
Tout ira simplement un peu plus vite, et la code review pourra rendre le code un peu meilleur
En même temps, l’absence de bons tests et le désir d’accélérer les déploiements rendront tout un peu pire
Au final, ce tiraillement produira un logiciel de qualité à peu près équivalente, mais allant un peu plus vite
Oui, le processus sera sans doute plus rapide, mais tout le reste restera pénible, donc personne ne le ressentira vraiment comme un grand changement
Il est même probable que tout le monde s’épuise plus vite
Si c’est complexe, c’est pour une raison, et on ne peut pas supprimer la complexité sans supprimer cette raison
Aucun outil ne peut résoudre un problème métier
À propos de la phrase « l’IA peut générer du code rapidement, mais cela ne veut pas dire qu’elle génère le bon code », dans les faits, le code est presque toujours correct
Ce qui me dérange généralement, c’est la manière dont il est ajouté
Quand on connaît suffisamment bien une codebase, il existe toute une série de rituels : où ajouter le code, comment nommer les choses, quelle quantité de commentaires mettre et où les mettre
Quand un agent échoue là-dessus, quelqu’un comme moi est agacé, et même l’écrire dans AGENTS.md ne semble pas suffire
Quant à l’idée que « si l’on donnait aux développeurs humains la même quantité de documentation sur les fonctionnalités et le périmètre, leur productivité exploserait », je travaille dans l’IT depuis presque 20 ans et je n’ai jamais cru que cela puisse vraiment arriver
Et même si cela arrive parfois, c’est trop rare pour que cela mérite discussion
Il suffit de comparer l’effort nécessaire pour reproduire un système déjà écrit avec celui qu’il faut pour construire ce système à partir de zéro
Il hallucine souvent, en particulier lorsque l’entrée est un bug ou un problème de performance, et sans accompagnement étroit il pose souvent un mauvais diagnostic
Cela dit, si on surveille ce qu’il fait et qu’on le pousse dans la bonne direction, il est bon en analyse de cause racine et en investigation, et il peut réellement améliorer l’efficacité
Je pense qu’un humain a une limite intrinsèque de vitesse pour assimiler et analyser l’information par rapport à une machine, ce qui place aussi un plafond aux gains de productivité
L’IA n’a pas besoin de contourner le processus, mais elle peut quand même accélérer les choses
Elle peut aider pour le refactoring, l’écriture de boilerplate, la détection d’erreurs inédites et de problèmes que les linters ne captent pas
Beaucoup de commentaires donnent l’impression soit de ne pas utiliser les processus standards connus, soit de supposer qu’avec l’IA il n’est plus nécessaire de les suivre
Peut-on livrer plus de code et plus de fonctionnalités ? Bien sûr, à condition d’avoir de bonnes exigences et suffisamment de tests
Tout code écrit par l’IA doit être relu et testé, et découpé en commits séparés et en pull requests distinctes
Quelqu’un qui ouvre une PR de plusieurs milliers de lignes, c’est un signal d’alerte
On ne ferait déjà pas ça sans IA, alors pourquoi le ferait-on avec l’IA ?
Les réécritures massives ou les grands refactorings sont les seules exceptions connues, mais même là, il vaut mieux avoir des commits individuels activables séparément pour qu’on puisse voir le cheminement des changements et juger plus correctement
Si l’on me montre un unique commit géant ou une PR énorme, je la refuserai
Il faut découper cela en morceaux qu’un développeur ordinaire puisse auditer