- Les LLM ont accéléré l’écriture de code, mais n’ont pas réduit la complexité intrinsèque de l’ingénierie logicielle
- À mesure que la génération de code devient plus facile, l’illusion se répand que l’expertise n’est plus nécessaire, et certaines organisations s’en servent déjà pour réduire leurs effectifs d’ingénieurs
- En réalité, la difficulté n’est pas l’écriture du code, mais la conception du système, la spécification, la validation et le maintien de la cohérence ; l’IA accélère même plutôt la charge dans ces domaines
- Le décalage entre spécification, tests et implémentation (
spec drift) s’aggrave rapidement, augmentant le risque d’effondrement de la fiabilité des systèmes
- C’est un schéma observé à répétition en plus de 40 ans de carrière : à l’époque de Visual Basic dans les années 1990, on a déjà vu réapparaître la même idée selon laquelle l’expertise n’était plus nécessaire, avant que la nécessité d’une discipline d’ingénierie ne soit finalement réaffirmée
- Les LLM sont d’excellents outils pour explorer des conceptions et accélérer les premières implémentations, mais ils doivent être utilisés pour renforcer la discipline d’ingénierie, non pour la remplacer
Une dangereuse illusion dans l’industrie
- Depuis que les LLM savent générer du code, une ambiance s’installe dans l’industrie logicielle selon laquelle l’ingénierie logicielle elle-même ne serait plus nécessaire
- Des disciplines comme l’architecture, la spécification ou la validation rigoureuse sont traitées comme des reliques d’un autre âge
- Dans certaines organisations, cette idée est déjà traduite en politique, avec des cas de licenciements massifs d’ingénieurs justifiés par les progrès de l’IA
- L’IA n’est que le dernier prétexte pour esquiver de mauvaises décisions business ou les pressions du marché
- Le fait de saisir des prompts dans une IA est de plus en plus présenté comme un substitut aux disciplines qui définissaient l’ingénierie logicielle
Un schéma historique qui se répète
- En plus de 40 ans de carrière, le même schéma a été observé à plusieurs reprises : apparition d’un nouvel outil → proclamation que les problèmes difficiles sont résolus → explosion de la productivité et démonstrations impressionnantes → réduction des effectifs → hausse de la complexité des systèmes → au final, des résultats très éloignés des attentes
- Les outils et les discours changent, mais le schéma lui-même ne change presque pas
L’analogie avec la maintenance aéronautique
- Le domaine de la maintenance aéronautique a beaucoup progressé grâce à l’amélioration des outils, au diagnostic informatique, aux manuels numériques et à l’interprétation par IA de la télémétrie, mais le besoin de techniciens expérimentés reste intact
- Un avion commercial est un système d’une complexité extrême, composé de millions de pièces et de milliers de sous-systèmes interconnectés
- Diagnostiquer un problème ne consiste pas seulement à utiliser le bon outil ou à suivre une checklist ; cela demande de l’expérience et du jugement sur la façon dont le système fonctionne dans des conditions d’exploitation réelles
- Aucune compagnie aérienne ne proposerait de supprimer les techniciens formés sous prétexte que les outils se sont améliorés, puis de confier les réparations à des agents de porte d’embarquement
- Pourtant, l’industrie logicielle est en train de tenir sur elle-même un discours très proche de celui-là
DIY vs systèmes professionnels
- Les projets hobby, les petites applications personnelles ou l’expérimentation de nouvelles idées ne posent aucun problème, et certaines des idées les plus passionnantes de l’histoire de l’informatique sont nées de ces expérimentations
- Mais le développement logiciel professionnel relève d’une tout autre catégorie : traitement des paiements, stockage d’informations sensibles, gestion d’infrastructures, exploitation de systèmes dont les gens dépendent chaque jour
- Les clients s’attendent naturellement à ce qu’un système fonctionne correctement, continue de fonctionner correctement en évoluant, et que les personnes qui le construisent comprennent comment il marche
- Ces attentes sont les conditions de base de l’ingénierie professionnelle, là où discipline et expertise deviennent inévitables
Le code n’a jamais été la partie difficile
- L’idée selon laquelle la difficulté du développement logiciel réside dans l’écriture du code est une vieille méprise
- Taper de la syntaxe a toujours été la partie la moins intéressante de la construction d’un système ; le vrai travail difficile consiste à décider du comportement du système, à concevoir les interactions entre composants et à préserver son intelligibilité à mesure que la complexité augmente
- Ce n’est pas un problème de codage, mais un problème d’ingénierie
- Réduire l’effort nécessaire pour produire du code n’élimine pas ces problèmes ; cela permet seulement de construire plus vite des systèmes plus grands et plus complexes
- Croire qu’il s’agit d’un gain de productivité est une illusion : la charge s’est simplement déplacée ailleurs
- La charge cognitive nécessaire à la revue du code et au traitement du code généré devient un frein à la productivité plus important que l’écriture elle-même
- Si la vitesse augmente alors que le comportement sous-jacent n’est pas suffisamment compris, cela ne fait qu’accélérer le moment où la complexité devient ingérable, avec en plus un résultat erroné
Un schéma déjà vu : l’époque Visual Basic
- Dans les années 1990, Visual Basic s’accompagnait déjà de promesses similaires : la programmation aurait été démocratisée, et l’expertise serait devenue inutile
- En pratique, Visual Basic a effectivement permis de créer de nombreuses applications qui n’auraient sans doute jamais vu le jour autrement
- Mais à mesure que les systèmes grossissaient et s’interconnectaient, on a redécouvert que produire des artefacts logiciels et concevoir des systèmes fiables, ce n’est pas la même chose
- Aujourd’hui, nous vivons une version amplifiée du même schéma : ce n’est plus seulement la barrière à l’entrée de la création d’applications qui baisse, mais celle de la production de code elle-même
- De là naît la tentation de croire que l’expertise n’est plus nécessaire
Le problème d’alignement
- Un logiciel fiable dépend d’un alignement dont on parle rarement en dehors de l’ingénierie
- Un système commence par une idée de son comportement → est documenté dans une spécification → puis des ingénieurs traduisent cette spécification en tests et en code de production
- Pour garantir la fiabilité d’un système sur le long terme, spécification, tests et implémentation doivent rester alignés en permanence
- Dès que ces trois éléments commencent à diverger, le système perd progressivement son intégrité
- La spécification décrit un comportement qui n’est plus implémenté
- Les tests ne valident qu’une partie du comportement et laissent le reste de côté
- Les ingénieurs arrivés plus tard devinent le comportement du système en lisant un code qui reflète, ou non, la conception d’origine
- Avec le temps, les suppositions s’accumulent, jusqu’à produire un système que plus personne ne comprend vraiment
- Ce phénomène est appelé
spec drift : l’écart progressif entre la description du système et le système lui-même
- Le code a changé, mais la spécification est restée identique
- La spécification a évolué, mais les tests sont restés figés
- Le comportement a changé peu à peu, au point que plus personne ne sait vraiment quelle était l’intention initiale
- Quand l’alignement est rompu, la fiabilité ne tient pas longtemps
L’IA accélère la dérive
- Les LLM accélèrent de façon spectaculaire la production de code, et c’est à la fois leur plus grande force et le point où le danger apparaît
- Quand le code est produit plus vite que les disciplines d’ingénierie qui l’entourent, les forces qui créent le
spec drift s’accélèrent elles aussi
- Des changements qui exigeaient autrefois une réflexion attentive et une implémentation manuelle sont désormais possibles en quelques secondes
- Des sections entières d’un système peuvent être réécrites avant même que quiconque ne vérifie si leur comportement reste conforme à la spécification
- Le code peut sembler raisonnable, compiler, être lisible, et même réussir les tests existants, alors que l’alignement qui gouvernait le système a peut-être déjà disparu
- Ce qui ressemble à de la productivité n’est en réalité que la capacité à aller plus vite vers le désalignement qu’auparavant
Là où l’IA aide réellement
- Les LLM ne sont pas une erreur, et utilisés avec discernement, ils peuvent améliorer de façon spectaculaire la manière dont les ingénieurs explorent et conçoivent les systèmes
- Ils excellent notamment dans le raisonnement sur un problème, l’exploration d’alternatives de conception, la synthèse de systèmes complexes et la production de brouillons qui accélèrent les premières étapes de l’implémentation
- Ils sont moins à l’aise dans les domaines qui exigent rigueur et cohérence dans la durée
- Maintenir l’alignement entre spécification, tests et implémentation reste une responsabilité d’ingénierie, et aucun outil ne peut s’y substituer, même s’il peut y contribuer
- La véritable opportunité consiste à utiliser les LLM non pas pour remplacer discrètement le processus d’ingénierie, mais pour le renforcer
L’ingénierie logicielle conversationnelle
- L’une des possibilités intéressantes ouvertes par les LLM est qu’une partie de l’ingénierie logicielle pourrait devenir plus conversationnelle
- Pendant des décennies, les outils de conception de systèmes sont restés rigides : les spécifications étaient des documents, l’architecture des diagrammes, et le raisonnement qui y menait se perdait dans les réunions et les discussions de couloir
- Avec les LLM, les ingénieurs peuvent explorer des idées de manière interactive, tester des hypothèses et travailler sur la conception d’une façon plus proche d’une conversation naturelle
- Mais la conversation n’est pas l’ingénierie : la conversation sert à explorer des idées ; l’ingénierie commence lorsque ces idées sont capturées sous une forme vérifiable, testable et maintenable
- Le défi des outils d’ingénierie de nouvelle génération sera d’apprendre à relier ces deux mondes sans perdre la discipline exigée par les systèmes complexes
L’expertise reste essentielle
- Les logiciels professionnels ont toujours besoin d’ingénieurs qui comprennent réellement comment fonctionnent les systèmes qu’ils construisent
- Les outils peuvent accélérer le développement, mais ils ne peuvent pas supprimer l’expertise nécessaire pour concevoir, raisonner sur et maintenir des systèmes complexes
- L’industrie est dangereusement proche d’oublier cette réalité
- Les LLM peuvent rendre des ingénieurs expérimentés bien plus productifs, mais ils ne remplacent pas la discipline d’ingénierie nécessaire à la construction de systèmes fiables
- Il faut utiliser ces outils efficacement, sans les idolâtrer
Aucun commentaire pour le moment.