- Pourquoi il est difficile de remplacer les développeurs par l’IA
- Beaucoup d’articles affirment que l’IA finira par remplacer les développeurs, mais dans la construction logicielle, la partie la plus difficile n’est pas le code : c’est de formuler des exigences claires et précises
- « Ce n’est pas un bug, c’est une fonctionnalité. Euh, attendez, si, c’est bien un bug. »
- Des exigences floues créent des bugs
- « Pour que l’IA remplace les développeurs, les clients doivent être capables d’expliquer exactement ce qu’ils veulent. Nous sommes en sécurité. »
La réalité de l’IA : échecs vs. voiture autonome
- L’IA a été utilisée avec succès dans des domaines aux règles limitées et clairement définies comme les échecs, mais la voiture autonome représente un défi bien plus complexe à cause d’une infinité de variables et de cas exceptionnels
- Dans la tech, les standards sont souvent de cinq ou six neuf de disponibilité (99,999 % à 99,9999 %)
- Atteindre 99 % ne coûte pas très cher. Cela signifie que votre site web peut être indisponible moins de 3 jours par an (87,6 heures)
- Mais chaque neuf supplémentaire fait augmenter le coût de manière exponentielle
- Pour atteindre 99,9999 %, il ne faut pas dépasser 31,5 secondes d’indisponibilité par an (99,9 % = 526 minutes / 8,76 heures, 99,99 % = 52 minutes, 99,999 % = 5,2 minutes)
- Cela exige énormément de planification et d’efforts, et bien sûr c’est coûteux
- Même si l’IA continue de s’améliorer, il y aura toujours un risque d’accident
- On ne sait pas exactement quel niveau d’accident sera acceptable, mais a minima elle devra être aussi performante qu’un humain
L’IA ne peut pas créer du logiciel, elle peut seulement produire du code
- Créer et maintenir un logiciel a bien plus en commun avec la conduite qu’avec les échecs
- Il existe d’innombrables variables, et les règles dépendent du jugement
- Quand on crée un logiciel, on a un résultat souhaité, mais ce n’est pas aussi simple qu’aux échecs
- Un logiciel n’est pratiquement jamais vraiment terminé. C’est un exercice continu d’ajout de fonctionnalités et de correction de bugs
- Contrairement au logiciel, une partie d’échecs s’arrête une fois gagnée ou perdue
- En développement logiciel, nous disposons d’un outil qui permet de transformer la conception logicielle en quelque chose proche du moteur de règles des échecs : les spécifications techniques
- Dans le meilleur des cas, ces spécifications techniques anticipent le comportement des utilisateurs et le déroulement du programme
- Mais c’est rarement le cas. Trop souvent, nous recevons une wishlist présentée comme une spécification fonctionnelle, ou bien un wireframe griffonné sur une serviette, ou encore un document d’exigences flou, et l’on nous demande de faire au mieux
- Pour aggraver les choses, les exigences changent et sont parfois ignorées
- Des exigences impossibles. Dans l’article d’origine, il est question d’un projet d’enquête COVID par SMS dans un endroit sans Wi‑Fi. Il n’aurait pas dû être lancé
- L’IA serait-elle réellement capable de gérer ce type de situation ?
- Pour que l’IA puisse produire un logiciel fonctionnel, il faut d’abord savoir exactement ce que l’on veut et être capable de le définir de façon claire et précise
- Ces dix dernières années, l’industrie du logiciel est passée du modèle waterfall à l’agile
- Dans le waterfall, on pensait que les parties prenantes savaient ce qu’elles voulaient et pouvaient le documenter, mais cette approche a échoué parce qu’elles étaient très déçues au moment de la livraison du produit final
- L’agile est une réponse à ce problème
- L’IA est peut-être surtout adaptée à la réécriture de logiciels existants pour les porter sur du matériel plus récent ou dans de nouveaux langages
- De nombreuses organisations utilisent encore des logiciels écrits en COBOL, mais presque plus personne n’apprend ce langage
- L’IA pourra peut-être reproduire plus vite qu’un humain un logiciel déjà construit, mais uniquement parce que quelqu’un a déjà réfléchi à la manière dont ce logiciel devait être conçu
- En utilisant le processus waterfall, ce que nous appelons parfois une marche à la mort, l’IA pourrait assez bien construire du logiciel
- Et qui est mauvais en waterfall ? Les humains
- Pas seulement pour la rédaction du document transmis ensuite à l’équipe de programmeurs, mais pour tout ce qui vient avant
- L’IA peut accomplir certaines choses impressionnantes, mais elle ne lit pas dans vos pensées et ne vous dira pas ce que vous voulez
8 commentaires
Je pense que cela s’applique non seulement au développement logiciel, mais aussi à tous les domaines de l’IA qui suscitent des inquiétudes.
Il est probable que les technologies visant à automatiser la validation des exigences progressent fortement. L’automatisation des tests devrait en tirer encore plus de valeur... Va-t-on vers un monde où les humains ne géreront plus que les cas de test... ?
« Dans une approche en cascade, qu’est-ce qui est le plus terrible ? Les humains, évidemment. »
Pour l’avoir vécu, je comprends tout à fait.
Bon, vous avez lu un bon article, alors allons maintenant trier les issues.
Même si l’IA aura peut-être du mal à remplacer les développeurs, si le développeur se contente de lancer quelques mots-clés, l’IA pourrait peut-être se charger du code, non ?
Ce qu’on racontait autrefois en plaisantant, le codage à la parole, pourrait bien devenir réalité..
N’est-ce pas déjà comme cela qu’on développe aujourd’hui en utilisant Copilot ou d’autres IA ?
Il suffit d’écrire en anglais, dans les commentaires, ce dont on a besoin, ils le génèrent automatiquement, et il ne reste plus qu’à vérifier si cela correspond ou non à ce qu’on veut.
Je suis tout à fait d’accord avec ce point de vue. Je pense qu’à l’avenir, tous les ingénieurs logiciel auront des compétences de type TPM et qu’on exigera cela d’eux.