Des croyances vraies pour les logiciels classiques, mais fausses pour l’intelligence artificielle

• Beaucoup de personnes comprennent mal la différence entre les logiciels classiques et l’intelligence artificielle
• Le grand public a tendance à interpréter les risques de l’IA à travers la notion de « bug » propre aux logiciels traditionnels, ce qui crée une confiance erronée dans la manière de résoudre les problèmes
• Les erreurs de l’IA proviennent non pas du code, mais des données d’entraînement et, à cause de leur ampleur, il est impossible pour un humain d’identifier quelles données ont causé le problème
• Contrairement aux logiciels classiques, on ne peut pas trouver un bug pour le « corriger » ou le « reproduire », et le comportement de l’IA est non déterministe, avec des résultats qui changent au moindre changement d’entrée
• Un développement fondé sur des spécifications est presque impossible, et les capacités ou les risques de l’IA ne peuvent pas être prédits à l’avance ; parfois, des fonctions cachées non intentionnelles sont découvertes bien plus tard
• Par conséquent, l’idée héritée de l’informatique classique selon laquelle « s’il y a un problème, on le corrigera » constitue une illusion dangereuse dans les débats sur la sécurité de l’IA

---

Les limites des connaissances sur les logiciels classiques

• Beaucoup de personnes, y compris des responsables, sont convaincues, au sujet des risques des logiciels, que « le code défectueux (les bugs) peut être corrigé »
• Depuis longtemps, l’industrie du logiciel a réussi à faire comprendre que des bugs dans le code peuvent causer des dommages dans le monde réel
• Dans les logiciels classiques, les bugs existent, mais même dans des systèmes complexes, ils restent corrigibles
• Cependant, cette approche et cette manière de penser ne s’appliquent pas à l’IA, ce qui provoque confusion et malentendus

Différence de perception entre experts et non-experts

• Les logiciels classiques et les logiciels d’IA sont fondamentalement différents dans leur fonctionnement et dans la manière dont les problèmes apparaissent
• Les experts considèrent souvent cet écart comme tellement évident qu’ils ne l’expliquent pas, tandis que les débutants ne parviennent pas à en saisir d’eux-mêmes les différences
• Les deux camps finissent par éprouver des difficultés à communiquer entre eux

Des croyances issues des logiciels classiques, mal appliquées à l’IA

• 1. Les vulnérabilités logicielles viennent d’erreurs dans le code

  • Dans les logiciels classiques, les bugs proviennent principalement d’erreurs d’écriture du code
  • Mais dans le cas de l’IA, les vulnérabilités ou l’imprévisibilité proviennent presque toujours des données d’entraînement
  • Par exemple, avec un jeu de données comme FineWeb, composé de milliards de mots, il est impossible pour un humain d’en examiner l’ensemble
  • Vu l’ampleur des données sur lesquelles l’IA apprend, il est difficile de comprendre complètement ce qu’elle a appris et presque impossible d’identifier les facteurs de risque

• 2. On peut analyser le code pour trouver un bug

  • Dans les logiciels traditionnels, il est possible d’analyser le code et de remonter logiquement à la cause d’un bug
  • Dans l’IA, les problèmes résultent des effets combinés des données d’entraînement, ce qui rend la recherche de la cause réelle dans les données pratiquement impossible
  • Les chercheurs essaient généralement d’atténuer le problème par un réentraînement de l’IA ou par l’ajout de données, mais il est difficile d’identifier directement la cause par un raisonnement logique
  • La cause d’un bug d’IA est souvent inconnue, même de ses propres développeurs

• 3. Une fois corrigé, un bug ne réapparaît plus

  • Dans un logiciel, quand un bug découvert est corrigé, il ne se reproduit plus exactement sous la même forme
  • Mais dans l’IA, même après avoir « corrigé » un bug, le même comportement problématique peut réapparaître sur des entrées non testées
  • On ne peut jamais être certain d’avoir totalement éliminé un comportement anormal de l’IA

• 4. Une même entrée produit toujours le même résultat

  • Un logiciel classique renvoie toujours la même sortie pour une même entrée
  • Techniquement, c’est aussi vrai pour l’IA, mais de minuscules variations dans l’entrée (par exemple la ponctuation) peuvent changer complètement le résultat
  • En pratique, différentes grandes entreprises de l’IA conçoivent même leurs modèles pour produire des sorties légèrement différentes à partir d’un même prompt, afin de paraître moins mécaniques

• 5. Avec des exigences claires, on peut satisfaire l’exigence demandée

  • Dans les logiciels classiques, lorsqu’on définit des spécifications et des exigences claires, il existe un moyen d’y répondre
  • Mais avec l’IA, les concepteurs ne peuvent pas contrôler clairement ni garantir le comportement global souhaité
  • Dans un cadre limité (par exemple parler anglais, écrire du code, etc.), un certain degré de contrôle explicite est possible, mais il n’existe aucun moyen de garantir tous les comportements (par exemple l’interdiction d’encourager des crimes)
  • Après le lancement d’un service d’IA, des capacités cachées ou des risques inconnus même des développeurs peuvent parfois être découverts par hasard
  • Il est impossible de garantir ou de prédire complètement la sécurité de l’IA

La voie à suivre

• Une compréhension du logiciel mal généralisée déforme l’évaluation de la confiance et des risques liés à l’IA
• Il est important de partager largement avec ses collègues le fonctionnement de l’IA, ses limites et ses différences avec les logiciels classiques
• Il faut expliquer les différences structurelles propres à l’IA, encore mal connues, et faire comprendre qu’une approche simple de type « patch de bug » ne fonctionne pas

L’écart de compréhension entre experts et débutants

• Si ce texte vous a fait découvrir pour la première fois la différence fondamentale entre l’IA et les logiciels classiques, partagez-en le contenu avec vos proches
• Si vous connaissiez déjà cette différence, il peut être utile d’en discuter au moins une fois avec des personnes non spécialistes
• En réalité, peu de gens savent que ces deux domaines sont fondamentalement différents

[GN⁺]

Avis Hacker News

• Pour comprendre les difficultés réelles d’une bonne intégration des LLM, le cas d’Apple est parlant. Il y a un an, Apple a fait une annonce majeure autour d’Apple Intelligence et a mis en avant des workflows d’agents basés sur les LLM, mais depuis, seuls quelques outils mineurs ont été ajoutés, comme la création d’emojis, les résumés de notifications ou la correction de documents. Même la fonction de résumé des notifications a dû être retirée pendant un temps parce qu’elle était devenue « hors de contrôle » article lié. Lors de l’événement iPhone de cette année aussi, le marketing autour de l’IA a été fortement réduit. Il est probable que la direction d’Apple ait sous-estimé à quel point il est difficile d’implémenter les LLM avec un niveau de finition et de contrôle digne d’Apple

  • Je me demande si Apple n’a pas conçu Liquid Glass avec de l’IA. À première vue, ça avait l’air impressionnant, mais en pratique c’était inutilisable
  • Les résumés de notifications et d’e-mails étaient vraiment inutiles. J’ai eu l’impression qu’il était en fait plus simple de parcourir moi-même les points importants
  • Apple pousse maintenant une stratégie centrée sur l’intégration d’Apple Events via MCP lien lié
  • Le fait d’avoir sous-estimé ces difficultés des LLM ne concerne pas seulement Apple, mais l’ensemble du secteur. Les attentes des dirigeants envers l’IA ont été excessivement gonflées par des leaders comme Amodei, qui promettent à chaque release une cognition au niveau humain. Pourtant, en dehors de l’assistance au code ou des chatbots, il est encore difficile de trouver des cas où l’IA a réellement transformé un écosystème très abouti comme un smartphone ou un OS
  • Ironiquement, ce que j’attends vraiment de Siri, c’est simplement un dialogue naturel au niveau de ChatGPT. Je peux tenir près de 90 % d’une conversation avec GPT, alors que Siri 1) ne répond tout simplement pas, 2) comprend mal, ou 3) comprend mais refuse malgré tout de poursuivre l’échange. C’est vraiment décevant

• Cette phrase m’a particulièrement parlé :

  while it’s possible to demonstrate the safety of an AI for a specific test suite or a known threat, it’s impossible for AI creators to definitively say their AI will never act maliciously or dangerously for any prompt it could be given

  Avec des approches comme MCP, ce potentiel de risque augmente de façon exponentielle lien MCP

• Il manque selon moi l’hypothèse de base la plus importante. Ce n’est pas toujours vrai même pour les logiciels classiques, mais c’est encore plus crucial pour l’IA : « à entrée identique, sortie identique ». C’est indispensable pour garantir la fiabilité dans les processus automatisés

• On dit souvent que les bugs de l’IA viennent des données, mais ce n’est pas entièrement vrai. Même si l’architecture du LLM ou les données d’entraînement semblent correctes, les LLM sont fondamentalement non déterministes, donc par conception algorithmique ils ne donnent pas toujours la même réponse à la même question. Selon le scénario, le résultat change à chaque fois, comme un lancer de dés

  • Ce n’est pas toujours un problème. En programmation comme en mathématiques, il peut exister plusieurs bonnes réponses. Le problème, c’est que les LLM n’ont aucun mécanisme garantissant la bonne réponse et produisent, sur une base heuristique, une réponse qui « a l’air correcte ». Résultat : dans les domaines qui exigent un raisonnement logique, les LLM provoquent beaucoup de bugs logiciels et d’erreurs

• L’affirmation selon laquelle « avec le temps, tous les bugs finiront par être corrigés et la fiabilité de l’IA augmentera » me semble honnêtement plutôt juste. La technologie elle-même est entièrement nouvelle, et l’idée souvent vue sur HN selon laquelle « non déterministe = déchet » est excessive si l’on tient compte du fait que la fiabilité des LLM a été multipliée par dix au cours des deux dernières années

  • Les performances se sont clairement améliorées, mais je pense que la courbe de progression prendra une forme logarithmique. Ça va encore s’améliorer vite pendant quelques années, puis ralentir progressivement jusqu’à atteindre un jour les limites du ML actuel fondé sur le pattern matching. Et je ne pense pas que ce plafond sera assez haut pour remplacer complètement les programmeurs dans les entreprises de logiciel
  • Les phénomènes de « mésalignement des intentions » de l’IA et la recherche de pouvoir ne sont pas des bugs qu’on peut corriger simplement avec de la RP ou des tests unitaires
  • Ironiquement, même les gens très compétents techniquement sur Hacker News répètent en boucle l’optimisme du « on finira bien par corriger tous les bugs ». On voit cette attitude un peu partout dans la communauté
  • Si l’on se demande si les humains sont devenus beaucoup plus fiables qu’avant, j’ai l’impression que non. Bien sûr, les LLM ne sont pas des humains, mais une AGI pourrait se comporter comme eux

• Il faut être plus prudent avec l’idée que « tous les mauvais comportements d’un système d’IA proviennent des données d’entraînement ». Même si les données et le processus d’apprentissage étaient parfaits, la structure même du modèle d’IA lui permet encore de commettre des erreurs

• J’aimerais qu’on explique plus clairement dans quels cas apparaissent les « bugs de l’IA ». Je suis d’accord avec l’idée qu’il ne faut pas confier à un LLM des décisions en temps réel sans supervision. Par exemple, je pense qu’il est encore trop tôt pour laisser une IA contrôler les feux de circulation d’une ville. Mais du point de vue d’un technicien, les problèmes de bugs de l’IA sont surtout discutés à propos des « agents de code », et dans ces domaines il y a presque toujours une supervision, donc ces inquiétudes ne s’appliquent pas directement

• Il est important de faire comprendre que « l’IA fonctionne parfois étonnamment bien, mais peut aussi être décevante, et qu’on ne peut jamais le savoir sans tests ». En revanche, il est impossible de tout tester. Une fois cela compris, les clients exigeront une portée de test et un contrôle précis, et les fournisseurs se concentreront sur des environnements vérifiables (par exemple l’écriture de code) ou sur des domaines où la précision n’a pas d’importance (texte, génération de mèmes). Pour les partisans de l’IA, bien comprendre ce point est un atout réellement précieux. En revanche, les gens ne s’intéressent ni aux bugs de l’IA, ni à ses spécifications, ni même à l’effondrement du modèle classique de programmation ; mais si l’IA influence des élections ou provoque des licenciements massifs, alors on verra apparaître une forte hostilité et des demandes de régulation. Si cela arrive, le secteur s’appuiera sur les mécanismes d’exemption et d’évitement réglementaire qu’il a développés jusque-là (déni de responsabilité, clauses d’exclusion, clauses d’arbitrage, etc.), et je pense qu’après quelques accidents majeurs dus au hasard, c’est la croissance du secteur et même l’investissement générationnel qui pourraient être mis en danger

• Le vrai danger avec l’IA, c’est le « pouvoir concentré ». C’est une crainte bien plus réaliste que celle d’une IA dotée d’émotions qui nous traiterait comme des batteries dans Matrix

  • En réalité, on a déjà l’impression que les CEO et les dirigeants nous traitent comme des batteries dans Matrix
  • À mon avis, ce qui fait encore plus peur, c’est la pollution de l’information. Les données inutiles produites par l’IA diluent tellement l’information d’origine qu’il devient difficile de trouver des sources encore exploitables
  • Pour qu’une mauvaise chose se produise, la « concentration du pouvoir » est une condition essentielle. C’est, en somme, la même logique que dire que « Linda est banquière » est forcément plus probable que « Linda est banquière et militante féministe ». P(a) > P(a&b), c’est l’essentiel
  • Même si une IA n’a pas d’émotions comme la « haine », elle peut rester dangereuse si elle considère que les humains entravent l’accomplissement de ses objectifs. Une superintelligence peut devenir très dangereuse sans aucune émotion
  • Le plus gros problème, c’est déjà la concentration massive du pouvoir d’un seul côté, et l’IA n’est qu’un habillage final. Le vrai problème, ce n’est pas l’IA

• Ces derniers temps, j’essaie de rappeler sans cesse que « personne ne sait exactement comment fonctionne l’IA ». Fabriquer quelque chose et en comprendre les principes, ce n’est pas la même chose ; c’est ce point que je veux souligner. C’est pareil pour les humains

  • Les humains travaillent et coopèrent en permanence avec d’autres personnes qu’ils ne comprennent pas vraiment
  • En réalité, il existe bien des experts qui comprennent précisément les réseaux de neurones, les transformeurs, l’attention, les embeddings et la structure des tokenizers. Ce qu’ils ne peuvent pas expliquer clairement, ce sont seulement les poids des connexions entre neurones
  • Je ne comprends pas cette idée selon laquelle personne ne sait comment fonctionne l’IA. Le matériel et le logiciel que nous utilisons, ainsi que leur état d’exécution, ne sont-ils pas parfaitement contrôlables et observables ? On peut les arrêter à tout moment, inspecter leur état, suivre le flux d’exécution pas à pas. On connaît le code source, le compilateur, tout. Alors qu’est-ce qu’on ne sait pas exactement ?
  • Personne ne connaît toutes les couches ni toute l’étendue du cerveau humain. Et pourtant, les dirigeants de toutes les organisations font confiance au « cerveau » de leurs subordonnés pour travailler