Les garde-fous d'un système IA

Toute cette série a décrit un même déplacement : l'IA produit, l'humain spécifie, vérifie, décide. Reste la question qui décide vraiment de la sûreté d'une fonctionnalité IA : sur quoi repose la confiance ? Trop souvent, sur un espoir — que le modèle « se comporte bien », qu'il ne se trompe pas, qu'il ne soit pas détourné. C'est le contraire d'une démarche d'ingénierie. Un composant probabiliste ne devient pas fiable parce qu'on le lui demande gentiment. On le rend sûr par conception : en l'entourant de contrôles qui, eux, sont déterministes. Ce dernier volet réunit les fils de la série autour d'une idée simple : le modèle est un composant qu'on ne contrôle pas — alors on contrôle tout ce qui l'entoure.

Traiter le modèle comme un composant non fiable

Le point de départ n'est pas pessimiste, il est lucide. Un grand modèle de langage produit une sortie probable, pas une sortie vérifiée. Il peut énoncer avec aplomb un contenu erroné — ce que le profil « IA générative » du NIST (AI 600-1) nomme une confabulation : un contenu « énoncé avec assurance mais erroné ou faux », familièrement une hallucination. Il peut aussi être détourné par ce qu'on lui donne à lire. En ingénierie, un composant dont on ne peut garantir la sortie porte un nom : un composant non fiable. On ne le supprime pas ; on l'enveloppe. C'est exactement ce qu'on fait, depuis toujours, autour d'une entrée utilisateur ou d'un service tiers : on ne fait pas confiance, on valide.

La sûreté ne se joue donc pas dans le modèle, mais dans le système qui l'entoure (Fig. 1). Autour du composant probabiliste, on dispose des contrôles déterministes : on valide ce qui entre, on valide ce qui sort, on limite ce que le système peut toucher, et l'on garde un humain aux étapes qui engagent. Le modèle reste au centre, faillible ; mais une défaillance de sa part ne se propage plus librement jusqu'à l'action ou l'utilisateur. C'est le sens de « sûr par conception » : la sécurité n'est pas une propriété qu'on espère du modèle, c'est une propriété qu'on construit dans l'architecture.

Quatre garde-fous autour d'un composant probabiliste

Ces contrôles ne sont pas une invention maison : ils recoupent les recommandations de sécurité de l'OWASP pour les applications à base de grands modèles de langage. Sa fiche « LLM01:2025 Prompt Injection » liste, parmi ses parades, la validation et le filtrage des entrées, la validation des formats de sortie attendus, le contrôle des privilèges et le moindre privilège, et l'approbation humaine des actions à risque. Quatre familles, qu'on peut lire comme les quatre côtés de l'enveloppe.

Valider l'entrée. Le premier garde-fou traite tout ce qui arrive au modèle comme suspect. C'est nécessaire parce qu'un modèle peut être détourné par sa propre entrée : l'OWASP définit une vulnérabilité d'injection de prompt comme le cas où « les prompts d'un utilisateur altèrent le comportement ou la sortie du modèle de façon inattendue ». La parade n'est pas de faire confiance au texte reçu, mais de le filtrer, de restreindre la manière dont il se mêle aux instructions du système, et de séparer le contenu externe non fiable des consignes. C'est le prolongement direct du context engineering : ce qu'on injecte dans le contexte n'est pas neutre, et une partie peut être hostile.

Valider la sortie. Le deuxième garde-fou refuse de croire le modèle sur parole. La fiche « LLM05:2025 Improper Output Handling » de l'OWASP vise précisément « la validation, l'assainissement et le traitement insuffisants des sorties générées par les grands modèles de langage avant qu'elles ne soient transmises en aval à d'autres composants et systèmes ». La règle est explicite : « traiter le modèle comme n'importe quel autre utilisateur, dans une approche zéro confiance », et valider ses réponses avant qu'elles n'atteignent les fonctions du back-end. Autrement dit : une sortie de modèle ne devient jamais une action ou un affichage sans être passée au tamis. C'est le point de contact avec l'évaluation des sorties : décider automatiquement, à l'échelle, ce qui est acceptable ou non.

Limiter les privilèges. Le troisième garde-fou réduit ce que le système peut faire, pas seulement ce qu'il peut dire. Dès que le modèle appelle des fonctions ou touche à d'autres systèmes, la fiche « LLM06:2025 Excessive Agency » de l'OWASP prescrit le moindre privilège : « limiter les permissions accordées aux extensions du modèle au strict minimum nécessaire ». La logique est robuste par nature : un système qui n'a pas accès à la production ne peut pas s'y tromper. Et l'autorisation d'une action se vérifie en aval, dans le code qui l'exécute — jamais en laissant le modèle décider lui-même ce qui lui est permis. Ce garde-fou devient central dès qu'un assistant cesse de suggérer pour agir sur la machine.

Garder l'humain aux étapes qui engagent. Le quatrième garde-fou n'est pas une politesse : c'est un contrôle d'architecture (Fig. 2). La même fiche OWASP LLM06 recommande de « recourir à un contrôle humain dans la boucle pour exiger qu'une personne approuve les actions à fort impact avant qu'elles ne soient entreprises ». Le droit le formule dans les mêmes termes : le règlement européen sur l'IA, à son article 14, exige que l'humain puisse « décider […] de ne pas utiliser le système, ou d'écarter, passer outre ou inverser sa sortie », et « interrompre le système au moyen d'un bouton d'arrêt » ramenant à un état sûr. L'humain n'est pas un spectateur : il est le dernier verrou, câblé dans le système, devant ce qui ne se rattrape pas.

Défense en profondeur, pas garantie

Il faut le dire sans détour, sous peine de vendre une fausse sécurité : ces garde-fous réduisent le risque, ils ne l'éliminent pas. Un filtre d'entrée n'attrape pas toutes les injections ; une validation de sortie ne détecte pas toutes les erreurs ; un humain dans la boucle peut valider par réflexe. C'est pourquoi on ne mise jamais sur un seul contrôle. On les empile — c'est le principe de la défense en profondeur : plusieurs couches indépendantes, pour qu'aucune défaillance isolée n'atteigne à elle seule l'action ou l'utilisateur. Aucune couche n'est parfaite ; c'est leur superposition qui rend le système résistant.

Cette honnêteté a une conséquence directe sur le garde-fou humain. L'article 14 du règlement européen impose que le superviseur reste conscient de « la tendance à se fier ou à trop se fier automatiquement » à la sortie d'un système — le biais d'automatisation, nommé jusque dans la loi. Un feu vert qui n'est qu'un clic réflexe n'est pas un garde-fou : c'est un tampon. Le contrôle humain ne vaut que si la personne exerce réellement son jugement — ce que le déplacement du métier vers la posture de réviseur a précisément mis au centre. Concevoir le garde-fou, c'est aussi le rendre effectif, pas seulement présent.

Le garde-fou comme synthèse : concevoir, c'est vérifier

Ce dernier volet referme la série sur son fil rouge. Tout ce qu'elle a décrit — évaluer les sorties, spécifier avant de générer, réviser plutôt que produire, ne rien laisser fuiter, laisser l'humain décider aux bons nœuds — n'était pas une collection de bonnes pratiques éparses. C'était, à chaque fois, la même chose vue sous un angle : intégrer la vérification dans le système au lieu de la confier à la bonne volonté du modèle. Les garde-fous sont l'endroit où cette idée devient de l'ingénierie concrète.

Car c'est bien là que le métier a basculé. Il ne s'agit plus seulement de produire du code, mais de concevoir l'enveloppe qui rend un composant probabiliste utilisable sans danger. Spécifier ce qui entre, vérifier ce qui sort, borner ce que le système peut faire, placer l'humain là où l'erreur coûte cher : concevoir ces garde-fous, c'est vérifier — non plus après coup, à la main, mais par construction, dans l'architecture elle-même. La bonne question n'est jamais « peut-on faire confiance au modèle ? », mais « le système tient-il, même quand le modèle se trompe ? ». Un système IA sûr n'est pas un système dont le modèle ne se trompe jamais. C'est un système conçu pour que ses erreurs n'aient nulle part où aller.