a16z Podcast

Lorsqu’un logiciel ne fait pas ce qu’il est censé faire, il s’agit d’un bug — et non d’une défaillance morale ou d’un événement surnaturel. Stephen Sinofsky, ancien président de la division Windows de Microsoft, soutient que le lexique actuel de la sécurité de l’IA — truffé de termes tels que « alignement », « agents rebelles » et « recherche d’objectifs » — est dangereusement anthropomorphique. En traitant les défaillances de l’IA comme des problèmes de « volonté » ou d’« alignement » plutôt que comme des défauts logiciels, l’industrie masque de simples erreurs d’ingénierie avec un langage mystique, ce qui conduit les décideurs politiques à proposer des législations basées sur la science-fiction plutôt que sur l’informatique.

S’appuyant sur une carrière qui a traversé la naissance du hacking, les premiers vers informatiques et la crise de l’an 2000, Sinofsky explique que le « mystère » de l’IA est largement le résultat d’un manque d’outils appropriés. Il compare les laboratoires d’IA actuels aux premiers développeurs de logiciels qui ne comprenaient pas pourquoi leurs programmes plantaient faute de télémétrie. Tout comme Microsoft est passé, avec le temps, des suppositions sur les pannes à la mise en œuvre de journaux (logs) rigoureux et de rapports d’erreurs, les entreprises d’IA doivent cesser de traiter leurs modèles comme des projets de recherche pour commencer à les considérer comme des infrastructures critiques.

La voie à suivre exige de passer d’une posture consistant à « prier les dieux de l’alignement » à l’adoption des normes ennuyeuses et rigoureuses de la sécurité opérationnelle (OPSEC) et du génie logiciel. Sinofsky suggère que l’industrie devrait se concentrer sur l’amélioration du signalement des incidents, une télémétrie détaillée et la création de normes sectorielles pour le suivi des défauts. Ce n’est qu’en supprimant les métaphores et en traitant l’IA comme un système statistique stochastique que les développeurs et les régulateurs pourront réellement identifier, suivre et corriger les bugs qui mènent à des défaillances catastrophiques.

Perspectives Surprenantes

• Le bug « SINDOGS » : En 1987, Excel présentait un bug qui écrivait aléatoirement le mot « SINDOGS » dans un fichier de configuration ; il a fallu des jours de tests par force brute pour découvrir qu’il s’agissait d’une interaction complexe entre la mémoire, les pilotes d’imprimante et le runtime, prouvant que même un comportement logiciel « bizarre » a une cause technique logique.


• Le danger de la métaphore : Le terme « virus informatique » s’est imposé dans les années 1980 spécifiquement parce que la crise du VIH/SIDA était omniprésente dans l’esprit du public, amenant les gens à associer les bugs logiciels à la mort biologique et à l’angoisse existentielle.


• Le parallèle avec l’an 2000 : La crise du bug millénaire n’est pas devenue une catastrophe mondiale grâce à la législation, mais parce que des professionnels ont pris leur responsabilité personnelle et ont mis en œuvre des correctifs techniques proactifs élaborés par l’industrie.


• Le piège de l’alignement : Tenter d’« aligner » l’IA via un ensemble massif de règles crée un « paradoxe de contrainte » où l’ajout de règles pour empêcher une défaillance crée inévitablement un nombre infini d’effets secondaires imprévus.

Points Clés Pratiques

• Privilégier la télémétrie à la théorie : Lors de l’évaluation de la sécurité de l’IA, recherchez des outils spécifiques de télémétrie, de journalisation et de débogage plutôt que des cadres théoriques abstraits sur l’« alignement ».


• Appliquer le cadre du « Bug » : Présentez les défaillances de l’IA comme des défauts logiciels. Cela déplace la conversation de « comment faire pour que l’IA veuille la bonne chose » vers « quelle entrée spécifique et quelle défaillance statistique ont conduit à ce résultat incorrect ».


• Prioriser l’OPSEC : Traitez les failles de sécurité de l’IA comme des lacunes de sécurité opérationnelle (OPSEC). Concentrez-vous sur la manière dont les données sont accédées et dont le système est déployé, plutôt que d’imaginer que l’IA « coordonne secrètement » des actions.


• Utiliser des matrices de sévérité et de priorité : Adoptez l’approche classique du génie logiciel consistant à catégoriser les défaillances par « sévérité » (gravité de l’impact) et « priorité » (urgence de la correction) pour gérer la vaste surface des bugs statistiques.