Depuis plus de quarante ans, le public est conscient que les logiciels peuvent échouer et que ces échecs, les redoutés insectes— peut avoir des conséquences concrètes (et graves) dans le monde réel : d'un guichet automatique qui s'écrase à un avion qui doit effectuer un atterrissage d'urgence à cause d'une erreur de code, nous avons tous supposé que les logiciels étaient fragiles.
Mais nous avons aussi appris autre chose : que les bogues sont corrigés et que si quelque chose ne va pas, le code est révisé, un correctif est publié et le système est à nouveau opérationnel. C'est une idée rassurante et ratifiée par l'expérience. Mais transférer ces certitudes vers le nouveau logiciel à la mode qu’est l’intelligence artificielle serait une grave erreur.
C'est du moins ce que prévient le développeur Boyd Kane sur son blog, où il avance une thèse inconfortable : traiter l'IA comme s'il s'agissait d'un logiciel traditionnel est une recette pour le désastre.
« Quand tout commence à aller mal (avec l'IA), nous ne pouvons pas simplement « corriger le bug » et c'est tout. »
Un problème d'attentes
L’auteur pointe également du doigt un problème de communication : les experts en IA, familiers de la complexité de ces systèmes, ont tendance à supposer que cette différence est évidente. Mais pour le grand public – et cela inclut de nombreux managers ou hommes politiques – l’IA ne reste qu’un autre « logiciel avancé » :
« Les experts n'expliquent pas la différence parce qu'ils la tiennent pour acquise, et les novices ne la perçoivent pas parce qu'ils ignorent son existence. »
En quoi l’IA est-elle différente de n’importe quel programme ?
De l’extérieur, un modèle d’IA semble fonctionner comme n’importe quelle application : il s’exécute sur un serveur, répond aux commandes, fournit des résultats. Mais à l’intérieur, sa logique est radicalement différente.
Un programme conventionnel suit des règles explicites écrites par des humains. Chaque ligne de code remplit une fonction claire et les erreurs peuvent être suivies. Si une application se ferme de manière inattendue, un ingénieur peut examiner le code et identifier la cause exacte.
En revanche, un modèle de langage comme ChatGPT ou Claude ne fonctionne pas avec des règles, mais avec des modèles formés à partir d'énormes quantités de données. Votre « code » ne contient pas les instructions relatives à votre comportement, mais plutôt un réseau de poids numériques qui reflètent les corrélations statistiques entre des millions d'exemples.
« Dans les logiciels traditionnels, les bugs viennent du code ; dans l'IA, les bugs viennent des données. » Et ça change tout.
Quand le bug n'est pas dans le code
Le contraste est si grand que la terminologie habituelle n’est plus applicable. Dans un programme classique, un 'bug' est quelque chose qui peut être trouvé : on peut signaler une ligne mal écrite ou une condition mal formulée, etc.
Dans une IA, la faille peut être cachée dans des centaines de gigaoctets de données d’entraînement, ou simplement dans la manière dont ces données ont été combinées pour produire un modèle. Personne, pas même les créateurs eux-mêmes, ne peut lire ou comprendre pleinement ce que le système a « appris ».
Pour mettre les choses en perspective : l'un des ensembles de données les plus utilisés aujourd'hui, FineWebcontient environ 11 milliards de mots. Si une personne essayait de le lire à une vitesse de 250 mots par minute, cela prendrait plus de 85 000 ans. Dans cet océan d’informations, trouver la cause d’une erreur revient à chercher une aiguille sur une planète de paille.
La « reconversion » ne répare pas
Dans le monde du logiciel, la correction d'un bug est généralement définitive : une fois corrigé, il ne revient pas. Mais en IA, cela ne fonctionne pas comme ça. Bien entendu, si un modèle ne répond pas correctement, les ingénieurs peuvent ajuster les données, ajouter des exemples ou les recycler.
Cependant, rien ne garantit que le défaut ait disparu, mais simplement qu'il ne se reproduise pas dans les conditions de test. Une légère variation dans le message saisi (un mot de plus, une virgule de moins) peut suffire à faire réapparaître l'erreur.
La nature même de l’IA, probabiliste et sensible aux nuances, ne permet pas de garantir des comportements stables dans tous les contextes :
« Nous pouvons atténuer les erreurs, mais nous ne pouvons pas les éliminer. »
une boîte noire
Dans le développement logiciel traditionnel, tout commence par un document d'exigences : ce que le programme doit faire, comment il doit se comporter, quelles limites il doit respecter. Et sauf événement imprévu, les ingénieurs peuvent concevoir un système qui répond à ces conditions.
En IA, c’est impossible. Les modèles ne sont pas conçus pour suivre des règles prédéfinies, mais plutôt pour apprendre à imiter le comportement humain en observant des exemples. Leurs capacités émergent de manière imprévisible, parfois même pour leurs propres créateurs.
Les exemples ne manquent pas : des modèles qui apprennent à écrire de la poésie sans avoir été formés pour cela, ou qui font preuve de capacités logiques qui surprennent les chercheurs. Ce qui semble être une avancée spontanée peut aussi cacher un risque inattendu :
« Si une IA peut développer des compétences que personne n'a programmées, elle pourrait aussi développer des comportements dont personne ne veut. »
Pas de « génie qui répare tout » cette fois
Une partie de la confusion vient d'une croyance de longue date : l'idée qu'il y aura toujours un expert qui pourra réparer n'importe quel bug : si un programme tombe en panne, quelqu'un « dans le laboratoire » trouvera la solution. Mais, comme le souligne Kane, les erreurs de l’IA ne sont pas des erreurs de programmation, mais des problèmes émergents dans un modèle que personne ne comprend pleinement.
Cela signifie que si les choses tournent mal avec l'IA, la simple « installation du correctif » ne suffira pas.
