Faire entrer l’IA dans le SI sans construire un deuxième SI incontrôlable

Le risque : un système parallèle sans propriétaire

Un assistant démarre souvent avec quelques documents et une clé API. Il devient utile, reçoit un accès au CRM, mémorise des échanges, déclenche des actions et finit par porter une partie du processus métier. Si ces extensions échappent aux règles du SI, l’entreprise obtient un second système : données recopiées, identités implicites, dépendances mal connues et exploitation sans responsable. La question pour une DSI est donc de définir comment cette capacité rejoint le système existant.

Notre recommandation d’ingénierie est de traiter l’IA comme un composant du SI. Le modèle fournit une capacité probabiliste ; les contrats, les droits, les états et les engagements de service restent explicites. Les recommandations qui suivent constituent une méthode de conception, pas le bilan chiffré d’un projet Digital Place.

Partir d’un service et de ses responsabilités

Décrire d’abord le service rendu : utilisateur, événement déclencheur, données nécessaires, sortie attendue, action possible et mode dégradé. Un assistant de préparation de dossier peut produire une synthèse sourcée sans disposer du droit de modifier le dossier. Une automatisation de classement peut proposer une catégorie sans décider d’un rejet. Cette distinction fixe les frontières avant de choisir un modèle ou un framework.

Attribuer un propriétaire métier, un propriétaire technique et un responsable d’exploitation. Définir qui accepte une nouvelle source, une permission ou un comportement. Le profil GenAI du NIST fournit un cadre de gestion des risques ; son application doit être traduite en décisions locales vérifiables.

Des contrats utilisables par le SI

Placer une API de service devant le runtime IA. Versionner les entrées, les schémas de sortie, les erreurs et les règles d’idempotence. Une sortie JSON conforme peut encore être fausse : la validation de schéma doit être complétée par des contrôles métier, des références sources et un traitement des valeurs inconnues. Éviter que chaque consommateur dépende directement du format d’un fournisseur.

OpenAPI permet de décrire les interfaces HTTP. Le contrat doit également préciser limites de taille, timeout, retry, annulation et éventuelle livraison asynchrone. Après un timeout d’écriture, consulter l’état de l’opération avant de la rejouer : une seconde tentative ne doit pas créer un second engagement métier.

Données et RAG : gouverner la récupération

Utiliser une récupération documentaire quand la réponse dépend d’informations internes ou évolutives. Un RAG ne corrige pas automatiquement la qualité des sources : inventaire, propriétaire, dates, droits et suppression restent nécessaires. Conserver une référence vers le document et le passage utilisé ; tester aussi l’absence de résultat et les contradictions entre sources.

Les droits doivent s’appliquer au moment de la récupération. Un index partagé qui expose un document à un utilisateur non autorisé constitue une fuite, même si le modèle répond poliment. Répercuter retrait d’accès et effacement dans l’index et les caches. Considérer le contenu récupéré comme une donnée non fiable, jamais comme une instruction capable d’étendre les permissions.

Identités et autorisations d’action

Distinguer identité de l’utilisateur, identité du service et délégation accordée à l’agent. Chaque outil doit vérifier l’autorisation sur la ressource visée avec une portée limitée. Un jeton large stocké dans le prompt n’est pas une délégation contrôlée. Les secrets restent côté serveur, avec rotation et audience définies.

Pour un connecteur MCP, la spécification d’autorisation 2025-11-25 décrit les mécanismes du transport HTTP. Elle ne remplace pas l’autorisation métier de chaque outil. Une action sensible doit être contrôlée au point d’exécution ; l’approbation humaine porte sur les paramètres exacts et sur un état encore valide.

Interchangeabilité : vérifier la sortie, pas seulement l’API

Isoler les fournisseurs derrière un adaptateur étroit : invocation, sorties structurées, outils, erreurs et comptage. Garder les prompts, politiques et corpus d’évaluation dans des artefacts versionnés. Tester un modèle alternatif sur les mêmes scénarios et documenter les écarts de qualité, latence, capacités et conditions de traitement.

Une interface compatible ne garantit pas un comportement équivalent. La réversibilité exige aussi export des données, reconstruction des index, capacité à relancer les évaluations et suppression des copies chez les prestataires selon les contrats. Prévoir une sortie praticable avant que les optimisations propres au fournisseur ne deviennent indispensables.

Coûts et runtime : mesurer le dossier terminé

Suivre coût par tâche aboutie, latence de bout en bout, appels d’outils, retries, consommation de contexte et escalades. Un coût par token faible peut masquer un parcours long ou de nombreuses reprises humaines. Tester une charge réaliste, avec documents longs, outils lents et files d’attente ; fixer des limites d’appels, de durée et de coût par exécution.

Choisir le chemin le plus simple satisfaisant les critères : règle déterministe, recherche, extraction, appel de modèle ou agent borné. Prévoir circuit breaker et mode manuel. Si une dépendance est indisponible, le service doit annoncer une limite et conserver un état cohérent, plutôt que produire une certitude fictive.

Observabilité utile et minimisation

Corréler demande, récupération, modèle, décisions de contrôle et appels d’outils. Les conventions HTTP OpenTelemetry fournissent des repères d’instrumentation ; les conventions GenAI évoluent dans leur dépôt dédié. Figer une version et éviter de prendre une convention expérimentale pour un contrat durable.

Les traces doivent permettre de diagnostiquer sans devenir une seconde base de données personnelles. Enregistrer identifiants de version, durées et motifs de contrôle ; limiter les contenus et masquer les secrets. Définir accès, durée de conservation et procédure d’incident avant d’activer une capture détaillée.

Évaluation, CI/CD et exploitation

Créer des scénarios représentatifs : réponse correcte, source absente, accès refusé, injection, outil en panne, reprise et annulation. Tester les schémas et les contrôles de manière déterministe ; répéter les essais du modèle pour mesurer la variabilité. Séparer jeu de développement et jeu de validation, puis examiner les erreurs par gravité plutôt qu’avec une moyenne unique.

Traiter changement de modèle, prompt, index ou outil comme un changement logiciel. Pipeline, artefacts versionnés, évaluation, déploiement progressif et retour arrière doivent porter sur l’ensemble. Le SSDF pour l’IA du NIST apporte un point d’appui pour intégrer le développement sécurisé au cycle de vie.

Une décision de mise en service explicite

Avant l’ouverture, demander une preuve pour chaque point : contrats stables, accès testés, données identifiées, budget respecté, scénarios adversariaux exercés, exploitation attribuée et restauration testée. Définir les SLO du service, les critères de suspension et la fréquence de réévaluation. Une démonstration réussie n’établit aucun de ces éléments à elle seule.

L’IA entre ainsi dans le SI avec ses capacités et ses limites. Pour Digital Place, les fondamentaux d’ingénierie permettent de rendre cette intégration contrôlable : une responsabilité, une interface et une preuve à chaque frontière importante.