Je manque de connaissance en IA pour bien comprendre pourquoi dans un cas ça marche et dans l’autre non, j’ai bien ma petite idée, mais c’est encore flou dans ma tête et je ne voudrais pas dire de bêtises.
Car tout simplement les deux ne sont pas comparables ?
Faire une IA experte dans un jeu assez cloisonné comme le Go ou les échecs c’est gourmand en calcul mais tu as moyen de converger vers de bons résultats car les possibilités restent limités par les règles du jeu qui sont faciles à faire respecter et parce que tu peux simuler quasiment n’importe quelle partie. Avec du calcul un peu bourrin et sans doute un peu d’optimisation maline tu as moyen d’avoir en effet de bons résultats en faisant analyser des parties passées + faisant jouer l’IA contre plein de joueurs et lui même.
Ici on fait ingurgiter une quantité astronomique de données en entrée sans que la signification profonde soit réellement explicité à la machine et on espère que l’IA va pouvoir recracher statistiquement le résultat attendu. C’est compliqué car ces situations sont potentiellement infinies, rien n’est borné car il n’y a pas de règles dans l’absolu, les données de qualité peuvent aussi manquer dans de nombreux contexte, il peut être difficile de s’assurer que dans toutes ces situations l’IA ne soit pas trop biaisé ni fasse de sur apprentissage, etc.
C’est pourquoi les LLM malgré le fait qu’ils sont bluffants sur certains aspects ne parviennent pas à réellement remplacer l’humain pour la plupart des tâches alors que pour d’autres tâches très spécifiques une IA surpasse l’humain si elle a été conçue dans un cadre très délimité permettant de simplifier l’entrainement et d’éviter des effets de bords car les possibilités de sorties sont aussi limitées.
Globalement, ces IA s’en sortent vraiment pas mal dans du code « d’entreprise », dans le sens que si elles ont accès au répertoire de travail, elles produisent du code cohérent (c’est-à-dire qui s’inscrit dans la continuité du projet, pas de nouvelle dépendance, réutilisation des fonctions déjà codées, style/norme de codage respectées, …) et souvent très bon dans ce contexte.
Après on peut se poser la question de la confidentialité de tout cela dans un contexte professionnel justement. D’autant plus si les données envoyées servent à l’apprentissage aujourd’hui comme dans le futur. Car les données d’entrainement peuvent facilement finir dans les sorties…
Notamment car il y a besoin encore d’avoir un esprit critique sur la sortie. Ce dont parle @Berdes par exemple. Même quand je dis « souvent très bon », ça veut dire aussi que parfois c’est pas très bon. Voir totalement non pertinent et ça c’est un problème. À la limite si on avait un truc qui était toujours acceptable même si pas toujours très bon ça passerait.
D’ailleurs j’ai eu le retour d’expérience d’un gars qui a voulu refaire un vieux jeu flash de mon enfance avec des technos web modernes qui était un sorte de Candy crush like (donc un style de jeu assez populaire et assez simple). Le gars n’est pas développeur (mais a l’habitude de jouer avec des IA pour tout et n’importe quoi), le code source et les assets étaient dispos et s’en est servi.
Il a passé pas mal d’heures pour produire un résultat convenable, proche du jeu d’origine mais avec quelques bugs ou divergences tout de même. Il y a du code parfois inutilement complexe pour pas grand chose, ou du code inutile (on réinitialise une variable qui n’existe pas).
Pour corriger ces soucis ça a été laborieux car il ne parvenait pas à décrire exactement le soucis à l’IA (en même temps, c’est difficile). Alors que je ne suis pas développeur web de métier, j’ai pu pointer les divergences avec le code d’origine bien plus vite qu’il n’a pu résoudre cela dans son coin. Car en lisant le code on identifie quand même assez nettement s’il y a une divergence entre l’intention et son implémentation.
Puis encore là on parle d’un prototype, après se poserait la question de son déploiement, si on voulait aller plus loin avec un système de login, des paiements ou autres ça pourrait vite devenir assez délicat à bien tester et s’assurer que tout aille bien. Savoir relire le code me semble nécessaire, surtout qu’il peut halluciner vraiment n’importe quoi.
L’idée c’est d’avoir une IA capable de créer un code et des spécifications et de les faire évoluer en fonction des retours utilisateurs. Encore mieux si elle est capable d’être pro-active dans l’établissement des spécifications et/ou la détermination du besoin.
À ce moment-là, on a vraiment supprimé le développeur. Quand le processus de réflexion autour du code est automatisé.
Et encore.
D’expérience, je n’ai jamais eu de specs vraiment clairs dans ma vie en point d’entrée dans un projet. C’était souvent flou, très haut niveau, alors parfois il y avait quand même assez de ressources pour bien commencer mais très souvent ça tenait sur un post it. Ma femme (pourtant pas dans le milieu) m’a déjà soumis une spec pour un petit programme eprso bien mieux foutus que mes clients pros. 
Quand j’étais junior j’allais un peu tête baissée en demandant naïvement de clarifier certains trucs. Avec l’expérience, j’ai appris à prendre du recul par rapport au contexte, à me mettre à la place de l’utilisateur pour comprendre ce qu’on veut obtenir pour ensuite proposer des solutions adaptées en plus de demander de clarifier. Car quand je demandais au début de juste clarifier pour mieux retravailler, très souvent on tombait dans des solutions assez boiteuses car finalement il manquait de vision ou de réflexion sur ce qui était voulu et l’objectif est vraiment d’améliorer cela. Je pense que c’est une valeur ajoutée pour le développeur d’agir ainsi et que les IA actuels sont bien loin de pouvoir fournir. Car il ne s’agit pas de juste raisonner autour du code, il faut raisonner sur le produit lui même aussi. Et plus on est de cerveaux et si possible de spécialités et d’expérience différentes dessus, plus on a de chances d’avoir de nouvelles idées pour faire mieux que si c’est le manager qui décide tout dans son coin dans sa tour d’ivoire. D’ailleurs je constate aussi le cas de pas mal de responsables produits qui ne consultent même pas les utilisateurs potentiels ou réels de leur produit avant de prendre des décisions…
De même pour la résolution de bogues. Je ne sais pas vous, mais les techniciens qui utilisent notre produit décrivent rarement très bien les problèmes qu’ils rencontrent. Il manque plein d’infos de base (version utilisée, config employée, actions précises effectuées pour reproduire le soucis). D’ailleurs la moitié du temps c’est plus un problème de formation et de documentation que des bogues réels. Il y a donc très souvent un jeu de questions / réponses et de devinette pour mettre le doigt sur le problème, et bon entre le problème et là où se situe le bogue dans le code il y a souvent un monde.
Avec en plus les IA qui ont tendance à faire du béni oui oui (tu dis qu’il est dans l’erreur, il essaye de se corriger quitte à faire pire que mieux ou à tenter l’impossible), je ne suis pas sûr qu’ils soient bien armés pour résoudre cela, en tout cas avec les technos actuelles.
Et pour revenir à l’expérience du non développeur qui refait un petit jeu avec ces outils, cela est cool car en effet des petits trucs simples peuvent être expérimentés par des non codeurs. Des scientifiques ou particuliers pourraient en effet faire quelques scripts ou petits programmes pour leur besoin comme ça, il y a quelques années sans un pro ou amateur pour le faire c’était souvent impossible pour eux. Mais tout n’est pas code (question du déploiement ou de l’intégration par exemple), tout n’est pas encore soluble avec ça (donc savoir lire le code en sortie est un vrai plus) et la culture reste essentielle. C’est difficile de formuler à la machine la logique d’un code quand tu ne sais pas coder, ni comment tu sais comment ça marche, si tu n’as pas les termes techniques dans certains cas qui restent indispensables, etc. Par exemple concernant le jeu développé ainsi, quelqu’un souhaitait l’intégrer à son système de login et d’enregistrement des scores, se pose la question de l’API à utiliser pour communiquer entre les deux projets. Bah quand tu ne sais pas ce qu’est une API ou en quoi ça consiste, ce n’est pas évident à mettre en place. D’où l’importance de la culture et des à côtés aussi.
Il y a de beaux pas à franchir encore donc.
Après j’ajouterais d’autres éléments malgré tout non négligeables que je trouve souvent passé sous le tapis.
Imaginons, on a une IA relativement fiable mais qui hallucine encore des conneries. L’IA fait une connerie et les conséquences pour celui qui s’en est servi pour développer avec sont importantes. Qui est responsable des dégâts et qui doit payer ? Ce n’est pas évident à répondre et cela préjugera de la confiance qu’on doit avoir dans la qualité de la sortie et donc de l’IA elle même.
Imaginons que l’IA pour s’améliorer récupère les données de tous les utilisateurs pour s’améliorer, comment s’assurer qu’aucun secret industriel ou données personnelles suite à ces ingestions ne ressortiront pas dans la nature ailleurs ?
Si l’IA a des capacités très importantes, pouvant gérer le code d’un projet, son déploiement, etc. Comment s’assurer que personne à l’extérieur ne peut attaquer l’IA pour altérer ce code, introduire du code malveillant ou autre ? Plus l’IA sera autonome, plus des attaques pourront aller loin, et on a pu le voir avec la question des prompts bien conçus ou des données d’entrainement empoisonnés permettaient facilement de contourner les protections mises en place, cela sera difficile d’ajouter des protections qui couvrent tous ces cas de figure. En particulier si l’IA utilise dans son entrainement des données non certifiées, soit en piochant sur Internet soit dans les données de ses utilisateurs.
Encore des questions à répondre et qui ne me semblent pas triviales à ce jour.