La partie la plus difficile de la construction d’un logiciel n’est pas le codage, ses exigences
Avec tous les articles sur tous les développements étonnants de l’IA, il y a beaucoup d’hésitations autour de la possibilité que nous, en tant que développeurs de logiciels, pourrions bientôt être sans emploi, remplacés par l’intelligence artificielle. Ils imaginent que tous les dirigeants d’entreprise et les chercheurs de produits contourneront la plupart ou la totalité de leurs développeurs de logiciels et demanderont directement à l’IA de créer exactement ce qu’ils pensent vouloir ou dont ils ont besoin. En tant que personne qui a passé 15 ans à créer des logiciels à partir des spécifications que ces gens créent, j’ai du mal à prendre au sérieux toutes ces inquiétudes.
Le codage peut être un défi, mais je n’ai jamais passé plus de deux semaines à essayer de comprendre ce qui ne va pas avec le code. Une fois que vous maîtrisez la syntaxe, la logique et les techniques, c’est un processus assez simple la plupart du temps. Les vrais problèmes sont généralement centrés sur ce que le logiciel est censé faire. La partie la plus difficile de la création de logiciels n’est pas d’écrire des codes qui créent les exigences, et ces exigences logicielles sont toujours définies par des humains.
Cet article parlera de la relation entre les exigences et les logiciels, ainsi que de ce dont une IA a besoin pour produire de bons résultats.
Ce n’est pas un bug, c’est une fonctionnalitépas d’attente, c’est un bug
Au début de ma carrière dans le logiciel, j’ai été placé sur un projet à mi-parcours afin d’aider à augmenter la vélocité de l’équipe. L’objectif principal du logiciel était de configurer des produits personnalisés sur des sites de commerce électronique.
J’ai été chargé de générer des termes et conditions dynamiques. Il y avait un verbiage conditionnel qui dépendait du type de produit acheté, ainsi que de l’État américain dans lequel se trouvait le client en raison d’exigences légales.
À un moment donné, j’ai pensé avoir trouvé un défaut potentiel. Un utilisateur choisirait un type de produit, ce qui générerait les termes et conditions appropriés, mais plus loin dans le flux de travail, cela permettrait à l’utilisateur de choisir un type de produit différent et des termes et conditions prédéfinis. Cela violerait l’une des caractéristiques explicitement convenues dans l’exigence commerciale qui avait la signature des clients.
J’ai naïvement demandé au client : Dois-je supprimer l’entrée qui permettait à un utilisateur de remplacer les bons termes et conditions ? La réponse que j’ai obtenue est gravée dans mon cerveau depuis. Ses mots exacts ont été prononcés avec une confiance complète et totale :
Cela n’arrivera jamais
Il s’agissait d’un cadre supérieur qui travaillait dans l’entreprise depuis des années, connaissait les processus commerciaux de l’entreprise et avait été choisi pour superviser le logiciel pour une raison. La possibilité de remplacer les termes et conditions par défaut a été explicitement demandée par la même personne. Qui diable étais-je pour interroger qui que ce soit, encore moins un cadre supérieur d’une entreprise qui nous payait de l’argent pour construire ce produit ? Je l’ai ignoré et l’ai rapidement oublié.
Quelques mois plus tard, quelques semaines seulement avant la mise en ligne du logiciel, un testeur côté client avait trouvé un défaut, et il m’a été attribué. Quand j’ai vu les détails du défaut, j’ai éclaté de rire.
Cette préoccupation que j’avais à propos de l’annulation des conditions générales par défaut, la chose qu’on m’a dit ne se produirait jamais ? Devinez ce qui se passait? Devinez qui a été blâmé pour cela et à qui a-t-on demandé de le réparer ?
Le correctif était relativement facile et les conséquences du bogue étaient faibles, mais cette expérience a été un thème récurrent dans ma carrière. J’ai parlé à suffisamment d’autres ingénieurs en logiciel pour savoir que je ne suis pas seul. Les problèmes sont devenus plus importants, plus difficiles à résoudre et plus coûteux, mais la source du problème est généralement la même : les exigences n’étaient pas claires, incohérentes ou erronées.
Débordement de pile
L’IA en ce moment : les échecs contre les voitures autonomes
Le concept d’intelligence artificielle existe depuis un certain temps, bien que les avancées très médiatisées aient suscité des inquiétudes dans les médias, ainsi qu’au Congrès. L’intelligence artificielle a déjà eu beaucoup de succès dans certains domaines. Le premier qui me vient à l’esprit est le jeu d’échecs.
L’IA a été appliquée aux échecs dès les années 1980. Il est largement admis que l’IA a dépassé la capacité des humains à gagner aux échecs. Ce n’est pas non plus surprenant, car les paramètres des échecs sont FINIS (mais le jeu n’a pas encore été résolu).
Les échecs commencent toujours avec 32 pièces sur 64 cases, ont des règles bien documentées et officiellement convenues, et surtout ont un objectif clairement défini. A chaque tour, il y a un nombre fini de mouvements possibles. Jouer aux échecs ne fait que suivre un moteur de règles. Les systèmes d’IA peuvent calculer les répercussions de chaque mouvement pour sélectionner le mouvement le plus susceptible de capturer une pièce adverse ou de gagner une position et finalement de gagner.
Il y a un autre front où l’IA a été très active : les voitures autonomes. Les constructeurs promettent depuis longtemps des voitures autonomes. Certains ont la capacité de conduire eux-mêmes, mais il y a des mises en garde. Dans de nombreuses situations, la voiture nécessite une surveillance active ; le conducteur peut avoir besoin de garder les mains sur le volant, ce qui signifie que la fonction d’auto-conduite n’est pas autonome.
Comme les programmes d’intelligence artificielle jouant aux échecs, les voitures autonomes utilisent en grande partie des moteurs basés sur des règles pour prendre des décisions. Contrairement aux programmes d’échecs, les règles sur la façon de naviguer dans toutes les situations possibles ne sont pas clairement définies. Les conducteurs font des milliers de petits jugements au cours d’un trajet donné pour éviter les piétons, contourner les voitures en double stationnement et tourner aux intersections achalandées. Obtenir ces bons jugements signifie la différence entre arriver au centre commercial en toute sécurité ou arriver à l’hôpital.
En technologie, la norme est de cinq ou même six 9 pour la disponibilité d’un site Web ou d’un service disponible 99,999 % (ou 99,9999 %) du temps. Le coût pour atteindre les premiers 99 % n’est pas si élevé. Cela signifie que votre site Web ou votre service peut être indisponible pendant plus de trois jours 87,6 heures par an. Cependant, pour chaque 9 que vous ajoutez à la fin, le coût augmente de façon exponentielle. Au moment où vous atteignez 99,9999 %, vous ne pouvez autoriser que 31,5 secondes d’indisponibilité par an. Cela nécessite beaucoup plus de planification et d’efforts et, bien sûr, coûte plus cher. Obtenir les premiers 99 % n’est peut-être pas facile, mais proportionnellement, c’est beaucoup plus facile et moins cher que cette dernière petite fraction.
365 X 24 X 60 minutes = 525 600 minutes par an
Disponibilité à 99 % -> indisponible pendant 5 256 minutes, 87,6 heures
Disponibilité à 99,9 % – > 526 minutes, 8,76 heures
99,99% -> 52 minutes, moins de 1 heure
99,999 % -> 5,2 minutes
99,9999 % -> 0,52 minute, environ 31,5 secondes
Peu importe à quel point l’IA est assez bonne, il y a toujours un risque d’accidents et de décès. Ces risques et conséquences se produisent tous les jours avec des humains au volant. Je ne sais pas quel taux d’accidents et de décès sera acceptable par les gouvernements, mais vous devez penser qu’il doit être au moins aussi bon que celui des êtres humains.
La raison pour laquelle il est si difficile d’obtenir ce niveau de sécurité acceptable est que la conduite d’une voiture implique beaucoup plus de variables que les échecs, et ces variables ne sont PAS FINIES. Les premiers 95 % ou 99 % peuvent être prévisibles et faciles à expliquer. Cependant, il y a tellement de cas extrêmes après ces premiers 99 %, et chacun peut partager certains traits, mais chacun est unique : autres véhicules sur la route conduits par d’autres êtres humains, fermetures de routes, construction, accidents, événements météorologiques.
Combien de fois avez-vous conduit après qu’une route a été goudronnée mais que la peinture des lignes de démarcation sur la route n’a pas été appliquée ? Il est beaucoup plus difficile de faire en sorte que votre modèle d’IA soit en mesure de prendre en compte et de reconnaître ces anomalies et ces cas extrêmes, et plus important encore, de réagir de manière appropriée sans entrer dans un accident. Chaque cas marginal peut partager certains traits, mais ils sont rarement identiques, ce qui rend plus difficile pour l’IA d’identifier la manière appropriée de réagir.
L’IA ne peut pas créer de logiciel, uniquement du code
La création et la maintenance de logiciels ont beaucoup plus en commun avec la conduite que le jeu d’échecs. Il y a beaucoup plus de variables impliquées et les règles sont basées sur des appels de jugement. Vous pouvez avoir un résultat souhaité lorsque vous créez un logiciel, mais il est peu probable qu’il soit aussi singulier que les échecs. Le logiciel est rarement fait; les fonctionnalités sont ajoutées et les bogues sont corrigés ; c’est un exercice continu. Contrairement aux logiciels, une fois qu’une partie d’échecs est gagnée ou perdue, c’est fini.
Dans le développement de logiciels, nous avons un outil pour rapprocher nos conceptions de logiciels du moteur de règles étroitement contrôlé des échecs : les spécifications techniques. Au mieux, les spécifications parcourent les comportements attendus des utilisateurs et les flux de programmes. Voici comment un utilisateur achète un e-sandwich : cliquez sur ce bouton, créez cette structure de données, exécutez ce service. Cependant, c’est rarement ce que nous obtenons. Trop souvent, on nous a remis des listes de souhaits sous forme de spécifications de fonctionnalités, de wireframes au dos de la serviette et de documents d’exigences peu clairs et on nous a dit de faire nos meilleurs jugements.
Pire encore, les exigences changent ou sont ignorées. Récemment, on m’a demandé d’aider une équipe à créer quelque chose qui pourrait aider les gens à obtenir des informations sur les problèmes de santé liés au COVID-19. L’application allait être pour une région du globe qui n’avait pas de WIFI fiable. L’équipe voulait que j’aide à créer une application qui pourrait faire des sondages via des messages texte SMSphone. Au début, j’étais ravie d’être impliquée.
Une fois que j’ai commencé à entendre l’équipe décrire ce qu’elle pensait vouloir, j’ai réalisé que cela allait être un problème. C’est une chose pour une entreprise de vente au détail de vous demander sur une échelle de 1 à 10 quelle est la probabilité que vous achetiez à nouveau dans son magasin. C’est très différent de poser des enquêtes en plusieurs étapes avec des questions à choix multiples sur les symptômes que vous ressentez avec une éventuelle infection au COVID. Je n’ai jamais dit non, mais j’ai évoqué tous les points d’échec possibles dans ce processus et je voulais que l’équipe définisse clairement comment nous traiterions les réponses entrantes pour toutes les questions. Y aurait-il des nombres séparés par des virgules associés à chaque réponse ? Que se passe-t-il si une réponse soumise ne correspond à aucune des options proposées ?
Après toutes ces questions, l’équipe est arrivée à la même conclusion. Nous avons décidé qu’il valait mieux ne pas passer par là. Croyez-le ou non, je dirais que c’était en fait un résultat réussi. Il aurait été plus inutile d’aller de l’avant sans une résolution claire de toutes les erreurs potentielles lorsque des données utilisateur non valides ont été soumises.
L’idée derrière l’utilisation de l’IA pour créer un logiciel est-elle simplement de permettre à ces mêmes parties prenantes de parler directement à un ordinateur pour créer une enquête par SMS ? L’IA va-t-elle poser des questions approfondies sur la façon de gérer tous les problèmes possibles de collecte de données d’enquête par SMS ? Est-ce que cela va rendre compte de toutes les choses que nous, en tant qu’êtres humains, pourrions faire de manière incorrecte en cours de route et comment gérer ces faux pas ?
Pour produire un logiciel fonctionnel à partir de l’IA, il faut savoir ce que l’on veut et pouvoir le définir clairement et précisément. Il y a des moments où j’écris des logiciels juste pour moi et je ne réalise pas certaines des difficultés et des défis jusqu’à ce que je commence réellement à écrire du code.
Au cours de la dernière décennie, l’industrie du logiciel est passée de la méthodologie en cascade à agile. Waterfall définit exactement ce que vous voulez avant l’écriture de tout code, tandis qu’Agile offre suffisamment de flexibilité pour que vous puissiez faire des ajustements en cours de route.
Tant de projets logiciels utilisant Waterfall ont échoué parce que les parties prenantes pensaient savoir ce qu’elles voulaient et pensaient pouvoir le décrire avec précision et le documenter, pour être très déçues lorsque le produit final a été livré. Le développement logiciel agile est censé être un antidote à ce processus.
L’IA pourrait être la mieux adaptée pour réécrire le logiciel que nous avons déjà, mais nous devons le réécrire pour utiliser un matériel plus récent ou un langage de programmation plus moderne. Il y a encore beaucoup d’institutions avec des logiciels écrits en COBOL, mais il y a moins de programmeurs qui apprennent à les utiliser. Si vous savez exactement ce que vous voulez, vous pourriez peut-être faire en sorte que l’IA produise des logiciels plus rapidement et à moindre coût qu’une équipe de programmeurs humains. Je crois que l’IA pourrait créer le logiciel qui a déjà été créé plus rapidement que les programmeurs humains, mais c’est parce que quelqu’un a compris ce que ce logiciel devrait faire en cours de route.
L’IA pourrait en fait très bien créer des logiciels en utilisant le processus en cascade, qui est aussi affectueusement connu sous le nom de marche de la mort. Vous savez qui est terrible à la cascade ? Nous sommes : des êtres humains. Et ce n’est pas à cause de la partie où les documents signés sont remis à une équipe de programmeurs afin qu’ils puissent écrire le code. C’est tout avant ça. L’intelligence artificielle peut faire des choses extraordinaires, mais elle ne peut pas lire dans votre esprit ou vous dire ce que vous devriez vouloir.