Il existe une hypothèse si profondément ancrée dans la façon dont les institutions pensent la sûreté technologique qu'elle n'a presque jamais besoin d'être énoncée : qu'un système peut être évalué à un instant donné, jugé sûr, et autorisé à fonctionner. Le travail de sûreté, une fois accompli, tient — jusqu'à ce que survienne quelque chose d'assez significatif pour exiger une réévaluation. L'argument de cette conférence est que, pour les systèmes intelligents, cette hypothèse échoue. Non pas parce que les méthodes d'évaluation sont mal conçues. Parce que l'hypothèse elle-même est structurellement inadaptée à ce que sont les systèmes intelligents.
La conférence s'ouvre en prenant cette hypothèse au sérieux plutôt qu'en la rejetant. Avant d'affirmer que la sûreté réactive (Reactive Safety) s'effondre pour les systèmes intelligents, elle explique pourquoi ce modèle a aussi bien fonctionné, et aussi longtemps — et nomme les trois conditions structurelles dont il dépendait. Les systèmes changeaient assez lentement pour qu'un certificat conserve sa validité. Les défaillances étaient assez locales pour permettre l'apprentissage. Les institutions avaient le temps d'assimiler les leçons avant que la même classe de problème ne se reproduise. La sûreté réactive est efficace précisément lorsque le rythme du changement reste inférieur au rythme auquel les institutions peuvent répondre. La question est de savoir ce qu'il est advenu de ces conditions.
Ce qui s'est produit n'est pas l'émergence de l'IA. C'est l'érosion progressive des trois conditions — par le changement logiciel continu, par une échelle qui a transformé des défaillances locales en événements systémiques, par une interconnexion qui a dissous la frontière de tout objet discret soumis à évaluation. L'IA a hérité de ce paysage érodé, puis l'a intensifié d'une manière propre à ce que sont les systèmes intelligents. La conférence nomme l'hypothèse fondamentale sur laquelle repose tout cadre de vérification — qu'il existe un moment où un système est suffisamment connu pour être évalué — et soutient que, pour les systèmes intelligents, ce moment n'existe pas. Non pas comme une limitation temporaire. Comme une caractéristique structurelle.
De là découle le piège du contrôle (Control Trap) — la réponse instinctive face à des systèmes invérifiables : resserrer les contraintes, restreindre l'enveloppe comportementale, exiger une évaluation exhaustive avant tout déploiement. La conférence ne rejette pas cet instinct. Elle l'examine avec précision. Le piège n'est pas que le contrôle soit une erreur. Le piège est qu'au-delà d'un certain seuil, davantage de contrôle détruit la propriété même qui justifiait la construction du système : sa capacité à opérer efficacement dans des situations qui n'étaient pas entièrement spécifiées au moment de sa conception. Un contrôle maximal produit une prévisibilité maximale — et produit simultanément une rigidité maximale. Un système qui ne fait que ce qui a été explicitement autorisé ne peut pas gérer ce qui n'a pas été explicitement anticipé. Or gérer ce qui n'a pas été explicitement anticipé est, en grande partie, la raison d'être de ces systèmes.
La conférence procède ensuite à une reformulation. L'ancienne question — comment rendre ce système sûr ? — présuppose que la sûreté est une propriété établie une fois pour toutes et conservée par la suite. La nouvelle question est différente par nature : comment rendre le processus de développement et de déploiement d'un système observable, vérifiable et corrigible ? Ce basculement entraîne trois exigences concrètes. L'observabilité : non pas la surveillance de modes de défaillance connus, mais la capacité de remarquer un mouvement dans des directions dont les conséquences pourraient s'avérer significatives — avant qu'elles n'aient été identifiées comme des risques. La vérification continue : non pas un événement produisant un jugement durable, mais une condition soutenue — qui est soit maintenue, soit autorisée à se relâcher, et la laisser se relâcher n'est pas neutre : c'est l'accumulation silencieuse d'un risque non caractérisé. La corrigibilité : non pas la disponibilité théorique d'une intervention, mais une capacité réelle d'agir à la vitesse et à l'échelle auxquelles le système se développe.
La conférence se termine en examinant les précédents — l'industrie pharmaceutique, l'énergie nucléaire, l'aviation civile — où cette transition s'est déjà produite : de la sûreté comme porte d'entrée à franchir, à la sûreté comme propriété continuellement maintenue d'un processus. Dans chaque cas, la transition n'a pas été motivée par une préférence, mais par la reconnaissance que le déploiement dans le monde réel dépassait ce qu'une évaluation finie pouvait couvrir. Cette même reconnaissance s'applique désormais aux systèmes intelligents — avec une urgence accrue, car le rythme de déploiement est plus rapide. L'affirmation finale de la conférence est précise : le pouvoir seul ne permet pas à une technologie de devenir une infrastructure. Ce qui le permet, c'est le développement de la confiance — non pas comme une disposition psychologique, mais comme quelque chose produit et soutenu par des institutions capables de porter des jugements fiables sur les systèmes qu'elles évaluent. Cette infrastructure n'existe pas encore à l'échelle que ce moment exige. La construire ou non est l'une des questions ouvertes les plus lourdes de conséquences dans le développement de l'IA. Pas la plus visible. Mais l'une des plus lourdes de conséquences.
