Ces derniers temps, j'ai lu des analyses intéressantes sur la raison pour laquelle la plupart des organisations naviguent essentiellement à l'aveugle avec leurs systèmes d'IA. Le problème central ? Nous déployons des outils que nous ne pouvons fondamentalement pas contrôler ni réparer lorsqu'ils tombent en panne.

Neel Somani, qui a mené des recherches approfondies en informatique couvrant la confidentialité et l'IA, souligne un point qui coupe à travers beaucoup de bruit autour du risque lié à l'IA. Tout le monde parle du scénario Skynet, n'est-ce pas ? La fin du monde. Mais ce n'est pas réellement le problème auquel la majorité des entreprises sont confrontées. Le véritable cauchemar opérationnel est plus simple et plus désordonné : vous utilisez des systèmes que vous ne pouvez pas déboguer, que vous ne pouvez pas modifier en toute confiance, et que vous ne pouvez certainement pas vérifier.

Réfléchissez à la façon dont l'IA fonctionne réellement dans la plupart des entreprises en ce moment. Un modèle signale une transaction comme frauduleuse. Il recommande quelqu'un pour un recrutement. Il ajuste les prix de manière dynamique. Puis il vous donne une explication après coup. Cela semble raisonnable. Sauf que voici le problème : cette explication est rétro-ingénierisée pour paraître plausible. Ce n'est pas nécessairement la façon dont le système est réellement arrivé à la décision. Changez une variable d'entrée et toute la logique s'effondre. Le récit ne correspond pas au mécanisme.

Cet écart crée deux risques opérationnels graves. Premièrement, les défaillances cachées. Lorsque la logique interne est opaque, les problèmes peuvent se propager de manière imprévisible, en dehors de tout test préalable. Une correction pour un problème casse silencieusement autre chose, généralement dans des conditions spécifiques que vous n'aviez pas anticipées. Deuxièmement, la fragilité de l'intervention. Même lorsque vous identifiez un problème, le corriger devient dangereux. Modifiez un composant et d'autres parties du système se compensent de manière à créer de nouveaux modes de défaillance. C'est comme jouer à whack-a-mole avec votre propre infrastructure.

Le cadre de Neel Somani se concentre sur quelque chose qu'il appelle la débogabilité. Pas l'interprétabilité — c'est différent. La débogabilité signifie trois capacités spécifiques : Pouvez-vous localiser quels mécanismes ont causé une défaillance ? Pouvez-vous modifier ces mécanismes précisément sans provoquer de dommages en cascade ? Pouvez-vous prouver que la correction a réellement fonctionné ?

La localisation consiste à identifier non seulement quelle couche d’un modèle a produit une sortie, mais aussi si ce comportement pourrait se produire sans ce mécanisme, ou si le mécanisme pourrait être actif sans produire ce comportement. L'intervention consiste à modifier les parties responsables de manière prévisible et ciblée, en éliminant le comportement indésirable dans votre domaine spécifié sans casser d'autres choses. La certification consiste à faire des affirmations exhaustives et falsifiables sur le comportement du modèle dans des domaines délimités — pas des garanties probabilistes, mais des affirmations universelles concrètes. Si cela échoue dans ce domaine, votre certification était fausse.

Pour la direction, les implications sont assez radicales. La gestion des risques traditionnelle repose sur la transparence et la traçabilité. Rattacher les décisions à des responsables. Les systèmes d'IA en boîte noire ? Tout ce cadre s’effrite. Les organismes de réglementation commencent à le remarquer. Le Règlement européen sur l'IA, les normes NIST, ils poussent tous vers l'explicabilité et la supervision. Mais voici le hic : vous pouvez réussir un audit et pourtant ne pas avoir la capacité technique réelle de réparer vos systèmes lorsqu'ils échouent en production.

Le théâtre de conformité ne suffit pas. La débogabilité change la question de « Sommes-nous documentés ? » à « Pouvons-nous réellement réparer cela ? » Lorsqu’un système d’IA se comporte mal, votre organisation peut-elle identifier la cause racine, modifier avec confiance, et vérifier que la modification a fonctionné ? Sans ces capacités, la gouvernance n’est que de la gestion de crise réactive. Vous imposez des revues, exigez de la documentation, imposez une supervision, mais rien de tout cela ne prévient la défaillance sous-jacente.

Somani établit un parallèle intéressant avec les logiciels critiques pour la sécurité. Vous ne pouvez pas prouver qu’un navigateur web ne crashera jamais. Mais vous pouvez prouver que certaines routines sont sûres en mémoire, que le sandboxing empêche certains exploits, que des invariants critiques survivent aux mises à jour, que les correctifs éliminent les vulnérabilités sans introduire de régressions. La même logique s’applique à l’IA. Un contrôle significatif ne concerne pas les garanties globales. Il s’agit d’assurances compositionnelles, limitées à un domaine. Garantir qu’un sous-circuit ne peut pas activer une fonctionnalité interdite sur des entrées spécifiées. Prouver qu’une intervention élimine un mode de défaillance tout en conservant d’autres comportements dans le périmètre. C’est ce qui compte pour les déploiements à haute enjeu — finance, santé, chaînes d’approvisionnement, modération de contenu.

La voie à suivre nécessite un investissement que la plupart des organisations n’ont pas encore priorisé. La vérification formelle, par exemple. Des preuves mathématiques établissant des propriétés logicielles. Traditionnellement appliquée aux contrôleurs d’avion et aux protocoles cryptographiques, l’étendre à l’IA est techniquement difficile mais pas impossible. Les avancées récentes dans l’extraction de circuits sparsifiés montrent que de grands modèles contiennent des sous-circuits isolés stables sous intervention. Les cadres de vérification neuronale démontrent que le raisonnement exhaustif fonctionne lorsque les modèles sont décomposés en composants vérifiables sur des domaines délimités.

Pour la direction, la décision est de savoir si attendre que ces méthodes mûrissent ou construire la capacité dès maintenant. Attendre comporte des risques. Le déploiement de l’IA s’accélère. L’écart entre ce que les organisations déploient et ce qu’elles contrôlent ne cesse de s’élargir. L’alternative consiste à investir dans des équipes comprenant à la fois l’IA et les méthodes formelles, à établir des standards internes pour déterminer quand la débogabilité est requise, à collaborer avec des fournisseurs qui privilégient des systèmes vérifiables plutôt que la commodité de la boîte noire. Cela implique de changer les décisions d’achat. Lors de l’évaluation d’outils d’IA, ajoutez une quatrième question au-delà de la précision, de la rapidité et du coût : Pouvons-nous réparer cela si ça casse ?

La plupart des discussions sur le risque lié à l’IA se concentrent sur les menaces externes — attaques adversariales, poisoning de données, acteurs malveillants. Des préoccupations légitimes, certes, mais elles détournent l’attention du problème fondamental. Pour la majorité des organisations, le risque principal n’est pas une IA weaponisée. C’est la défaillance opérationnelle ordinaire et le manque d’outils pour y répondre. C’est un problème de gouvernance, pas une question technologique.

L’argument central de Neel Somani : le but ultime de la gestion des risques liés à l’IA n’est pas une meilleure surveillance ou plus de supervision. C’est construire des systèmes débogables avec la rigueur que la sécurité critique exige aujourd’hui. Jusqu’à ce que cela devienne une pratique standard, les organisations déploient des systèmes qu’elles ne contrôlent pas vraiment. Pour tout dirigeant, la question n’est pas si l’IA va transformer votre secteur — elle l’a déjà fait. La vraie question est si votre organisation saura réellement le gouverner quand cela comptera.