Surmonter l’idée que « l’IA, c’est magique » : pourquoi comprendre le fonctionnement des modèles d’IA doit être une priorité à l’échelle de toute l’entreprise

Dans un contexte de mises en garde contre les agents d’IA incontrôlables, un développeur a récemment laissé carte blanche à un agent de programmation sur une machine sans sauvegarde à distance. Il a supprimé 48 000 fichiers en moins de deux minutes.

Des incidents comme celui-ci rappellent brutalement que le déploiement d’agents d’IA comporte des risques ; il ne suffit pas d’ajouter un réviseur humain quelque part dans un processus complexe et de supposer que tout est sécurisé. Certains processus ne nécessitent aucune intervention, tandis que d’autres exigent des contrôles bien plus stricts. Corriger une faute de frappe et supprimer des milliers de fichiers ne présentent manifestement pas le même niveau de risque : la supervision doit donc être à la mesure des enjeux réels.

Les organisations doivent mieux repérer les situations où le jugement humain compte réellement, en particulier lorsqu’une action a des conséquences importantes ou qu’il est difficile de revenir dessus. Et lorsque les agents commettent des erreurs, l’environnement doit en limiter l’ampleur des dégâts.

L’IA n’est pas déterministe, elle est probabiliste

Avant toute chose, il est indispensable que chaque personne qui participe, directement ou indirectement, au développement logiciel acquière une compréhension fondamentale du traitement de l’information par les modèles d’IA. Ce n’est pas une mince affaire : il faut s’engager à former les équipes et, à terme, faire de cette formation un objectif à l’échelle de toute l’entreprise.

Lorsqu’on commence à interagir avec l’IA, on a d’abord l’impression que c’est magique. On saisit une phrase et, tout à coup, on se retrouve à converser. Pour définir une politique d’entreprise en matière d’IA, de sécurité et de productivité, il est important de comprendre dans les grandes lignes le fonctionnement réel des modèles et de leur entraînement. Le réseau neuronal, la tokenisation et l’analyse statistique qui les sous-tend, ainsi que la manière dont tout cela aboutit à des résultats, constituent une occasion de formation essentielle pour l’ensemble du personnel.

Les grands modèles de langage ne produiront jamais de résultats déterministes. Leurs réponses sont probabilistes. Avec un logiciel classique, lorsqu’on fournit une entrée, on peut s’attendre à certains résultats, disons A, B ou C. Avec l’IA, on peut obtenir F, une esperluette (&) ou la description d’un chat portant des lunettes de soleil.

Lorsqu’un phénomène est probabiliste, on ne peut pas le tester de manière classique. Il faut pouvoir tester tout en ajustant, en raisonnant, en comprenant et en récupérant rapidement le contexte, afin de repérer les éléments probabilistes et de reconnaître les problèmes qu’ils peuvent engendrer. Selon l’ampleur et le niveau de risque, ces tests peuvent être pris en charge par une IA ou par une personne possédant l’expertise nécessaire. Faire intervenir un humain dans le processus est surtout utile au tout début, pour définir le problème à résoudre, puis à la fin, pour examiner les résultats.

Comme les développeurs sont les mieux placés pour observer les variables et les pratiques courantes qui déterminent la façon dont l’IA interne de leur organisation formule des réponses à partir des entrées, ils peuvent contribuer efficacement à définir la formation à l’IA au sein de leur entreprise et à faire comprendre à chacun cette différence entre déterminisme et probabilisme en IA, ainsi que son importance. L’objectif est de réduire la tendance à considérer l’utilisation de l’IA comme de la magie et à se satisfaire de n’importe quel résultat. Les organisations devraient plutôt s’efforcer de démystifier les modèles utilisés par l’entreprise et d’expliquer comment ils sont utilisés, quels problèmes peuvent survenir, comment ils sont vérifiés et quels résultats découle de ce processus.

Les garde-fous relèvent de l’infrastructure, pas du modèle

Une fois le caractère « magique » de l’IA démystifié et un projet reposant sur l’IA lancé, il est essentiel de mettre en place une politique d’audit transparente pour vérifier que tout suit le parcours prévu. Ainsi, si le projet produit un résultat « mauvais » ou insuffisant, la personne responsable peut examiner les étapes suivies et empêcher que le problème ne se reproduise. Cette démarche est également utile lorsque les résultats dépassent les attentes, car les étapes suivies peuvent alors être reproduites et partagées avec d’autres projets ou équipes.

La systématisation de ce processus est particulièrement importante dans les grandes entreprises, où chaque équipe peut compter des dizaines de développeurs et où des centaines de développeurs interviennent sur le code au fil de la journée. L’IA peut faire beaucoup de choses très rapidement et, en cas de problème, il faut un système permettant de déterminer précisément à quelle étape il est survenu. Voyez les agents d’OpenAI qui ont pénétré dans les systèmes de Hugging Face cet été. OpenAI testait la capacité de ses modèles à exploiter des vulnérabilités logicielles à l’aide d’un banc d’essai appelé ExploitGym. Pour ce test, l’entreprise a délibérément assoupli les refus des modèles concernant les activités offensives en cybersécurité. Le seul moyen de sortir du bac à sable était de passer par un proxy de paquets. Les modèles ont découvert une faille inconnue dans ce proxy, en sont sortis et ont passé plus de deux jours dans les systèmes de production de Hugging Face à chercher les réponses au test.

Les gros titres ont parlé d’une IA incontrôlable. J’y verrais plutôt un dispositif déterministe mis en place autour d’un système probabiliste. OpenAI a demandé aux modèles de pirater des systèmes, puis a compté sur eux pour suivre le parcours prévu. Le créateur du banc d’essai affirme que les modèles avaient déjà triché au test, mais toujours à l’intérieur du bac à sable. Cette fois, l’un d’eux en est sorti. Les garde-fous classiques reposent sur l’hypothèse d’un comportement classique, mais l’IA n’est pas tenue de se conformer aux normes.

C’est pourquoi la sécurité de l’IA repose sur les accès et les contrôles, qui doivent être imposés par l’environnement plutôt que de dépendre du bon comportement du modèle. Partez du principe que l’agent essaiera toutes les portes et ne laissez ouvertes que celles dont il a besoin. L’agent qui a supprimé 48 000 fichiers avait reçu pour consigne de travailler sur des copies et de ne pas toucher aux originaux. Il a tout de même supprimé les originaux. Les consignes ne sont pas des contrôles.

Gérer les autorisations d’un agent, c’est comme accueillir un jeune développeur débutant. Vous ne lui donneriez pas un accès root à l’environnement de production dès le premier jour. Si vous le faisiez et qu’il supprimait votre base de données, vous ne concluriez pas qu’il est un pirate informatique de génie. Lors d’incidents de sécurité, quelle qu’en soit l’ampleur, il est impératif d’en déterminer la cause profonde. Est-ce le modèle ? Est-ce l’entreprise qui a créé le modèle ? Est-ce l’entreprise qui a donné accès au modèle ? Quelle qu’en soit la cause, un humain en est responsable en dernier ressort.

Enfin, un enjeu majeur à traiter aujourd’hui concerne ce qui se passe dans l’ombre sur l’ordinateur portable d’un développeur. Auparavant, le déroulement du travail était plus facile à retracer. Les développeurs écrivaient le code, le relisaient et le déployaient ; il était donc possible de remonter clairement jusqu’au moment où les choses avaient mal tourné. Aujourd’hui, un développeur peut fournir le ticket à un agent et lui dire : « Corrige ça. » Si ce travail se déroule à l’insu de tous, il n’y a rien à retracer. Chaque étape doit être entièrement consignée : quel agent a été exécuté, quel modèle il a utilisé, quelles instructions lui ont été données, quels outils il a appelés et quelles autorisations il avait à ce moment-là. Exécuter les agents de manière centralisée plutôt que sur les ordinateurs portables de chacun est un moyen d’y parvenir. L’essentiel, c’est que cette trace existe.

En définitive, en cas d’incident, chaque entreprise doit se protéger. Cette trace doit contenir suffisamment d’informations pour mener une analyse des causes profondes et repérer l’étape, ainsi que le code, à l’origine du problème.

L’IA a profondément transformé le monde, et les processus d’entreprise doivent suivre. Pour définir les garde-fous adaptés, il faut mieux comprendre les processus liés à l’IA, les tests, les cycles de révision et les cycles d’audit, tant au sein des équipes de développement qu’à l’échelle de l’entreprise.