Les développeurs de logiciels devraient aborder les contrôles de programmation basés sur l’IA avec autant de zèle que de prudence : aucune IA ne devrait être conçue sans que le technicien qui la met en oeuvre ne comprenne comment et pourquoi elle peut fournir les fonctions qu’elle promet.
Les générations ayant passé leur permis de conduire ne vivent pas l’expérience du véhicule autonome comme la vivront peut-être des jeunes de la Génération Z et au-delà, s’ils n’apprennent plus à conduire. Les pilotes de ligne sont dans une situation comparable quand ils utilisent les fonctions de pilotage automatique : ils apprennent tous à piloter un avion sans assistance avant d’envisager de passer aux commandes numériques. Comme l’intelligence artificielle (IA) se manifeste désormais dans des applications grand public à tous les niveaux imaginables, peu d’utilisateurs auront besoin de comprendre pleinement les mécanismes du code et le traitement de données effectués en arrière-plan pour rendre l’application « intelligente ». Cependant, les ingénieurs en logiciel, les développeurs ou les programmeurs, ne peuvent se positionner au même niveau que les utilisateurs finaux et s’affranchir de leur responsabilité.
Les développeurs, des garde-fous nécessaires
Alors que la programmation automatisée enrichie à l’IA se développe rapidement, les concepteurs de logiciel doivent vraiment garder cela à l’esprit. Même si depuis un certain temps, des progrès notables ont été réalisés en matière de « complétion de code », on constate aujourd’hui que l’IA et l’apprentissage machine (ML) automatisent de nombreuses tâches de base qui faisaient autrefois partie du travail de développement de n’importe quel logiciel et les développeurs en assumaient le rôle.
Sur le plan positif, nous savons que les programmeurs de logiciels peuvent désormais utiliser l’IA pour ingérer et traiter les données de télémétrie et les fichiers de logs créés par les applications logicielles et les services de données pendant leur exécution. Cela peut permettre aux ingénieurs de prévoir de manière proactive les raisons profondes des défaillances et proposer des solutions de contournement aux gestionnaires de systèmes et aux utilisateurs finaux eux-mêmes.
Tout aussi bénéfique est le recours à des couches de codage d’IA pour rechercher les « signaux dans le bruit » créés par les applications. Au moment de l’agrégation de ces données, ces couches peuvent permettre à l’équipe de génie logiciel d’automatiser des flux de travail communs et donc de créer plus rapidement des extensions de fonctionnalités logicielles et, espérons-le, de manière plus robuste, dans la mesure où leur usage a déjà été validé par ailleurs.
Le cas de GPT-3 sous surveillance
Ce sujet suscitera inévitablement des discussions autour de la technologie GPT-3, ou Generative Pre-trained Transformer 3 (GPT-3). Ce modèle de langage autorégressif (il tire parti du caractère aléatoire) utilise une forme de ML pour créer des textes et des phrases de type humain. Il peut également servir à créer du code logiciel pour la génération de texte en utilisant d’énormes volumes de données de formation. Tout le monde n’est pas convaincu des avantages du GPT-3 et une certaine méfiance se manifeste à l’égard des humains qui confient la puissance de l’écrit aux ordinateurs.
Vous avez dit « fake news » ? Pas impossible. « L’intervention de l’IA dans les processus d’automatisation, quel que soit le processus, est généralement réalisée par étape, autant dans un souci de prudence que d’efficacité », a déclaré Riccardo Bocci, directeur de la gestion des produits chez IFS, une entreprise spécialisée dans les ERP dans le cloud. L’IA doit d’abord servir à accroître les compétences et les connaissances des experts et non à instaurer une « automatisation totale à tout prix ». « Ce sont les connaissances des experts qui servent de vrai support au développement de toute application d’IA digne de ce nom et je ne pense pas qu’elles seront entièrement remplacées de sitôt », a ajouté M. Bocci. Ce dernier insiste sur le fait qu’une compréhension de base du fonctionnement des techniques d’IA et ML est fondamentale pour faire les bons choix lors de l’examen d’une boîte à outils prête à l’emploi. « J’ajouterais que, même pour le praticien de l’IA chevronné, ce niveau de compréhension technique n’est pas suffisant. Il doit aussi être capable d’apprécier le problème métier qui vraiment en jeu », a-t-il ajouté.
La prudence récompensée
Si l’industrie du logiciel utilise efficacement les progrès de l’IA au niveau des outils de codage, les équipes de développement seront plus rassurées sur le fait qu’elles utilisent le bon outil pour le travail à effectuer dans un cas d’utilisation donné. C’est un cercle vertueux : utiliser les bons outils pour créer les bons éléments de la base de code de n’importe quel logiciel d’entreprise signifie que les données, la logique et les modèles d’affaires dans lesquels ce logiciel sera exploité seront plus performants. « En tant que spécialiste des données, je pourrais réécrire tous les algorithmes que j’utilise à partir de zéro, mais ce serait extrêmement inefficace en termes de temps et de compétences alors que je peux facilement utiliser un modèle en accédant à une bibliothèque Python via une interface de programmation d’application (API) », a déclaré Adam Lieberman, responsable de l’intelligence artificielle et de la gestion de la maintenance chez Finastra, un éditeur de logiciels de services financiers. « Cela signifie-t-il que je finirai par perdre les compétences dont j’ai besoin pour comprendre et construire des algorithmes ? Bien sûr que non. Si les développeurs veulent que les modèles écrivent du code pour eux, ils doivent comprendre ce qu’ils demandent de faire au modèle ».
Il est peut-être réconfortant de se rappeler que tout pilote de ligne digne de ce nom pourra contourner toutes les commandes du pilote automatique et se passer des commandes électriques pour continuer à piloter son avion. Peut-être devrions-nous appliquer cette même méthode aux applications logicielles d’entreprise (en particulier les applications critiques) et nous donner la possibilité de nous arrêter pour demander à l’équipe de programmation : connaissez-vous les algorithmes qui pilotent ces fonctions en profondeur, ou nous avez-vous simplement donné la version Lego avec des éléments de base rapidement assemblés ? Si votre équipe de développeurs ne sait pas que Lego vient des deux premières lettres du mot danois LEG GODT, qui signifie « bien jouer », alors vous avez un problème.