Après une maîtrise en IA et plus de vingt ans à relier des systèmes, « il reste seulement à brancher le modèle » me rend encore nerveux. Le branchement sérieux contient identité, données, contrats d’API, validation, traces, coût, déploiement et retour arrière.

Je dessinerais un pipeline où le modèle n’accède jamais directement aux systèmes de référence :

client -> API métier -> authentification -> collecte autorisée
                  -> construction de requête -> passerelle modèle
                  -> sortie structurée -> règles -> révision
                  -> décision finale -> écriture métier séparée

L’API métier établit le contexte à partir de l’identité, pas d’un identifiant de client librement fourni. La collecte lit une version précise des sources. La passerelle garde les secrets, applique timeout, limite de coût et liste de modèles. Le modèle retourne un schéma attendu, par exemple :

{
  "categorie": "dossier_incomplet",
  "champs_manquants": ["preuve_adresse"],
  "source_ids": ["doc-184-v3"],
  "abstention": false
}

Le parseur refuse un JSON invalide, une catégorie inconnue ou une source absente. Des règles déterministes vérifient limites et cohérence. Une sortie bien formée n’est pas nécessairement vraie; la révision humaine reste la décision au premier déploiement.

Une trace pour distinguer les pannes

Chaque exécution porte un identifiant et conserve :

1. versions des sources et de leur permission;
2. modèle, version, paramètres et gabarit de prompt;
3. sortie brute protégée et sortie validée;
4. règles déclenchées et délai de chaque étape;
5. décision humaine et corrections structurées;
6. coût et nombre de jetons;
7. version du code et environnement.

Cette trace permet de séparer quatre causes : donnée d’entrée mauvaise, récupération incorrecte, modèle inadéquat ou intégration défectueuse. Sans elle, chaque incident devient « l’IA s’est trompée » et l’équipe change le prompt au hasard.

Je commencerais en shadow mode. Le processus officiel continue; le pipeline produit une proposition sans droit d’écriture. Les écarts alimentent un jeu d’évaluation par catégorie. Une nouvelle version passe ce jeu hors ligne, puis reçoit une petite fraction de cas en parallèle. On compare qualité, abstention, délai et coût avant de promouvoir.

Le droit d’écriture appartient à un service séparé. Il reçoit une décision approuvée et un identifiant idempotent, applique l’autorisation métier et écrit une transaction. Après un timeout, il lit l’état avant de reprendre. Le modèle ne possède ni mot de passe de base ni outil général executer_sql.

La panne se dégrade vers le processus manuel. Les files sont bornées et expirent; on ne rejoue pas demain une suggestion devenue vieille. Un paramètre coupe une version, une passerelle révoque sa clé et les opérations incomplètes sont réconciliées. Le rollback de code ne doit pas supposer qu’une migration de données est réversible; les schémas évoluent par étapes compatibles.

Le NIST traite le risque sur le cycle de vie entier, ce qui remet le modèle à sa place. Je ne fixe pas un ratio universel entre modèle et intégration. Je demande plutôt si l’équipe peut montrer la trace, reproduire le test, borner le coût, couper le droit et continuer sans le fournisseur. Tant que ces réponses manquent, le système reste en lecture seule, même si la démo sait déjà écrire.