IA en production : qui valide une décision que le modèle peut changer ?

Un assistant IA peut réussir une démonstration et rester difficile à autoriser en production. La difficulté n’est pas seulement de juger ses réponses : il faut aussi décider qui approuve les données qu’il consulte, les changements apportés à son comportement et les actions qu’il peut déclencher. Si ces responsabilités sont tacites, une anomalie devient vite un débat sur « qui devait vérifier ».

Imaginons une PME qui souhaite utiliser un assistant pour préparer des réponses à des demandes clients à partir de sa documentation interne. Le scénario est fictif. Le besoin semble circonscrit, mais plusieurs décisions se croisent : le métier juge-t-il les réponses acceptables ? Qui autorise l’accès aux documents ? Qui valide une nouvelle version ? Et qui peut suspendre le service si les réponses se dégradent ?

Le sujet est distinct du choix du niveau d’autonomie de l’agent : il porte ici sur le circuit de décision et les preuves nécessaires pour autoriser un système IA à évoluer et à rester en service.

Le cas fictif : un pilote utile, mais sans propriétaire de l’approbation

Dans ce scénario, une équipe prépare un pilote interne. Les utilisateurs veulent gagner du temps pour retrouver des informations, tandis que l’IT doit intégrer l’assistant à un outil existant. Une première série d’essais paraît encourageante, mais le comité de lancement ne sait pas qui doit signer la mise en production.

Le responsable métier connaît les réponses attendues, l’équipe technique connaît les composants, et la personne responsable des données sait quels documents peuvent être consultés. Aucun de ces rôles ne couvre à lui seul toutes les décisions.

La réponse n’est pas de réunir tout le monde à chaque changement. Il s’agit de séparer les décisions selon leur objet et leur impact. Un vocabulaire plus technique ne remplace pas une autorité clairement attribuée : le comité doit pouvoir relier chaque approbation à un périmètre, à une preuve et à une personne redevable.

Trois approbations différentes, plutôt qu’un feu vert global

Ces rôles peuvent être tenus par des personnes déjà présentes dans une PME. L’important est de nommer un approbateur final, sans lui demander de se substituer aux spécialistes : il décide sur la base de leurs validations et peut refuser le lancement si une preuve manque.

Une chronologie simple pour éviter l’approbation de dernière minute

1. Cadrer l’usage. Le métier décrit la tâche, les utilisateurs concernés, les réponses ou actions attendues et ce que l’assistant ne doit pas faire. Une demande trop large rend l’évaluation et l’approbation difficiles.

2. Définir les données et les responsabilités. L’IT et le responsable des données précisent les sources accessibles, les personnes qui en autorisent l’usage et la manière de signaler une modification du périmètre. Une nouvelle collection de documents ne doit pas être traitée comme un simple ajustement technique.

3. Évaluer sur des situations préparées. Le métier choisit des exemples représentatifs, y compris des cas où l’information manque ou ne permet pas de répondre. L’équipe consigne les critères de réussite et les limites observées, plutôt que de s’appuyer sur une impression générale.

4. Préparer l’exploitation avant le feu vert. L’équipe technique documente comment identifier une version ou une configuration, qui peut suspendre le service et comment revenir à une procédure manuelle ou à un autre fonctionnement déjà accepté par l’entreprise.

5. Décider sur un périmètre explicite. L’approbateur consigne ce qui est autorisé, pour quels utilisateurs et sous quelles réserves. Une évolution importante des données, des actions disponibles ou de l’usage déclenche une nouvelle revue adaptée à son impact.

Le circuit de décision à rendre visible

Le parcours peut tenir en une séquence lisible : besoin métier défini → données et accès autorisés → scénarios évalués → exploitation préparée → décision de lancement consignée. Si une étape échoue, le dossier revient au rôle concerné plutôt que de transformer le feu vert final en validation implicite de tout le projet.

Ce circuit aide aussi à traiter les incidents. Si les réponses deviennent inadaptées, l’exploitation peut appliquer la procédure prévue, tandis que le métier décrit l’effet observé et que l’IT vérifie le périmètre technique. La décision de réactiver le service revient ensuite à l’autorité désignée, sur la base de contrôles convenus. Ce scénario doit être préparé ; il ne constitue pas le récit d’un incident réellement survenu.

Checklist avant d’autoriser l’usage

• Le besoin, les utilisateurs et les usages hors périmètre sont décrits.

• Une personne est nommée pour chaque validation : métier, données, exploitation et décision finale.

• Les sources de données autorisées et les changements qui imposent une revue sont identifiés.

• Les critères d’évaluation et les cas où le système doit s’abstenir sont consignés.

• Une procédure de suspension et une solution de continuité sont définies.

• La décision indique le périmètre autorisé, les réserves et les preuves examinées.

Cette répartition complète le cadrage du projet IA autour du problème métier : elle traduit le besoin en décisions d’exploitation. Si le système peut aussi appeler des outils ou déclencher des actions, les garde-fous d’un agent IA connecté au SI méritent une évaluation spécifique.

Le 14 octobre, InfoQ annonce un panel gratuit de 60 minutes consacré à l’IA en production, avec cinq praticiens. Les sujets annoncés incluent l’autonomie des agents et l’approbation humaine, la vérification des changements générés par l’IA, l’exposition de données sensibles et le RAG en production.

Les personnes inscrites peuvent soumettre des questions et recevront l’enregistrement. Pour une PME, la question à préparer reste très concrète : quelles décisions sont déléguées à l’équipe projet, et lesquelles exigent une approbation explicite avant le lancement ou après un changement important ?