Au-delà du battage médiatique : l'IA ne peut pas résoudre la complexité essentielle du logiciel

Introduction : Le loup-garou de la complexité logicielle n’est pas impressionné par l’IA

De tous les monstres qui peuplent les cauchemars de notre folklore, aucun ne terrifie plus que les loups-garous, car ils peuvent se transformer de manière inattendue du familier en horreur. Pour ceux-ci, nous cherchons des balles d’argent qui peuvent magiquement les mettre au repos. Le projet logiciel familier a quelque chose de ce caractère […], généralement innocent et simple, mais capable de devenir un monstre d’échéances manquées, de budgets explosés et de produits défaillants. Alors nous entendons des cris désespérés pour une balle d’argent, quelque chose pour faire chuter les coûts logiciels aussi rapidement que les coûts du matériel informatique.

— Fred Brooks, No Silver Bullet-Essence and Accidents of Software Engineering

Près de quatre décennies plus tard, l’insight de Fred Brooks de 1986 est toujours d’actualité—et rappelons-nous que c’est le cerveau qui a dirigé l’OS/360 légendaire d’IBM, le méga-projet des années 1960 qui a été pionnier des systèmes d’exploitation distribués.

Les avancées en ingénierie logicielle ont largement ciblé les difficultés accidentelles, résolvant des problèmes comme la manipulation de chaînes, les mathématiques en virgule flottante et la gestion de la mémoire avec des langages de plus en plus puissants et abstraits. Les grands modèles de langage (LLM) sont les derniers dans cette lignée de progrès, mais ils ne sont pas une balle d’argent.

La complexité essentielle du logiciel

Malgré les grandes visions vantées par les luminaires technologiques comme Sam Altman, Dario Amodei et Mark Zuckerberg qui disent tous que les LLM finiront par coder tout seuls, la réalité de l’exécution de projets logiciels majeurs raconte une histoire bien plus sobre. Le professeur Bent Flyvbjerg fournit un contrôle de réalité crucial, notant que même si 40% des projets informatiques réussissent dans les budgets, les autres 60% échouent de manière spectaculaire, avec un dépassement de coût moyen de 450%.

Ce n’est pas qu’une statistique abstraite. Regardez le tristement célèbre système de paie Phoenix du Canada, qui frôle les 1000% de dépassement (de 300 millions estimés à 2,6 milliards dépensés). On peut penser aussi au dépassement de coût du projet SAAQClic au Québec qui est passé d’un estimé de 500 millions à 1,1 milliards dépensés. Et avant d’incriminer une gestion amateur, rappelons que ces projets étaient supervisés par un géant de l’industrie, IBM.

Le cas de SAAQClic est révélateur : l’organisation a cédé à une vieille « balle d’argent » : les plateformes no‑code; en l’occurrence, SAP. L’idée, c’est qu’en achetant un système clé en main plutôt qu’en en développant un sur mesure, on éviterait la complexité. En réalité, il faut plier le modèle conceptuel de son métier à celui du fournisseur. Évidemment, SAP n’intègre pas la notion d’immatriculation automobile : la SAAQ a donc dû faire entrer des immatriculations dans la fiche client SAP. L’essentiel de la migration a ainsi consisté à faire entrer des carrés dans des cercles, en rattachant toutes les immatriculations à un client SAP. Problème : l’immatriculation d’une remorque, par exemple, est perpétuelle ; certaines datent de plusieurs décennies et sont associées à des clients décédés depuis longtemps.

Le professeur Bent Flyvbjerg a dérivé une loi de puissance pour les dépassements de coûts dans les projets informatiques. De manière similaire, Fred Brooks a remarqué que les canaux de communication entre les travailleurs croissent de manière quadratique avec le nombre de travailleurs, ce qui l’a fait conclure que le ralentissement d’un projet serait proportionnel au carré de la main-d’œuvre qu’on y ajoute. Déprimant, n’est-ce pas ?

Plus n’est pas toujours mieux. L’IA agentique est dans le battage, mais peut-être que mettre plus d’agents IA au travail n’aiderait pas beaucoup s’ils se comportent comme des humains…

Il est vraiment difficile de faire converger un grand projet logiciel vers sa forme finale ; la divergence est la norme. J’ai vu de nombreuses fois des projets grandir en taille et remarquer que le taux de bugs de régression augmente à un point où les nouvelles fonctionnalités sont éclipsées par la quantité de problèmes qu’elles introduisent.

Comment nous abordons traditionnellement la complexité

Malgré tout cela, nous ne pouvons pas résoudre de gros problèmes sans une grande équipe ; c’est à ce moment que la complexité commence à s’immiscer.

Nous savons que les entreprises FAANG sont notoirement sélectives dans leurs processus d’embauche parce qu’elles comprennent que quelques individus peuvent faire dérailler ou diverger un projet prometteur.

L’ingénierie logicielle consiste à créer des abstractions qui sont aussi étanches que possible, minimisant les effets entre les composants non liés, et gardant ces composants aussi faiblement couplés que possible. C’est une bataille constante pour maintenir la complexité basse et la simplicité haute.

Alors, pourquoi tout ce battage ?

Quelles “difficultés accidentelles” les LLM résolvent-ils qui ont déconcerté les technologies précédentes ? La liste est remarquable :

• Résoudre les défis algorithmiques : J’ai regardé ChatGPT résoudre des problèmes LeetCode de difficulté moyenne en une seule invite. Des problèmes plus complexes, “difficiles”—le genre qui teste vraiment les ingénieurs chevronnés—peuvent souvent être résolus avec juste quelques itérations d’invites. Historiquement, la compétence à ce niveau était un ticket pour un emploi bien payé dans une entreprise technologique de premier plan. Vous ne me croyez pas ? Regardez celui-ci sur la recherche de la plus longue sous-chaîne sans caractères répétés :

Je n’ai même pas pris la peine de copier le texte du problème, j’ai juste jeté une capture d’écran et il l’a résolu en un coup.

• Concevoir des structures de données : Les LLM ont internalisé le canon des structures de données classiques. Ils démontrent une capacité remarquable à combiner ces structures de manière créative, adaptant les solutions pour répondre aux besoins spécifiques d’un problème.

• Optimisation des performances : J’ai personnellement vu ChatGPT transformer des requêtes SQL lentes en versions qui s’exécutent dix fois plus rapidement. Cette puissance n’est pas limitée au codage général. Un ancien collègue, professeur de recherche opérationnelle Jean-François Côté, note que ses étudiants utilisent l’IA pour reformuler des modèles de programmation linéaire complexes en variations plus efficaces et bien établies.

• Refactorisation intuitive : Les outils de refactorisation déterministes ont besoin d’instructions précises. En contraste, vous pouvez donner à un LLM une commande de haut niveau comme “Convertir cette logique conditionnelle en héritage”, et il exécutera le changement dans le parfait style Martin Fowler—pas besoin de définir manuellement les portées, paramètres ou conditions.

Et la liste continue. Le battage est là parce que les LLM peuvent résoudre une vaste gamme des difficultés accidentelles en ingénierie logicielle, et ceci constitue un énorme développement.

Conclusion

Cependant, comme l’a dit le lauréat du prix Nobel en informatique pour son travail sur l’apprentissage profond :

Nous n’atteindrons pas l’AGI en augmentant l’échelle des LLM.

— Yann LeCun, https://www.youtube.com/watch?v=4__gg83s_Do

LeCun a aussi noté que nous avons besoin de modèles mentaux et d’abstractions pour naviguer dans le monde. La pensée hiérarchique nous aide à faire cela en divisant une grande tâche, comme un voyage de New York à Paris, en une série d’étapes plus simples. Nous n’avons pas à penser à chaque détail à la fois, comme comment nous allons quitter notre maison ou quelle rue prendre. Nous pouvons abstraire ces détails et nous concentrer sur un objectif plus simple, comme “aller à l’aéroport”.

Selon lui, les LLMs seraient incapables d’une telle prouesse, une limitation que je considère comme rédhibitoire. C’est pourtant cette même capacité qui forme le socle de l’ingénierie logicielle. Celle-ci transcende la simple maîtrise des algorithmes pour devenir l’art d’architecturer des niveaux d’abstraction synergiques, dont les propriétés émergentes apportent des solutions à des problèmes d’une grande complexité.

Enfin, disons que nous réussissons à augmenter l’échelle des LLM vers une AGI ou les faire penser de manière hiérarchique. Malheureusement, l’intelligence seule ne suffit pas à tuer le loup-garou de la complexité logicielle. Les grands ingénieurs logiciels ont une peur profondément enracinée de la complexité et une volonté agressive de l’éliminer. Vous avez besoin de ce genre d’instinct de survie pour gérer de grands projets, vous avez besoin de cicatrices ; comment rendre les LLM plus craintifs quand ils génèrent du code ? Les constructions logicielles sont des cathédrales d’abstraction que personne ne comprend complètement. Vous ne pouvez pas juste leur jeter du code ; vous avez besoin d’une approche plus humble et de constamment refactoriser votre pensée du système avec lequel vous traitez. Est-ce que tout cela rentre dans une fenêtre de contexte LLM ?