- La plupart des équipes savent brancher un modèle. Beaucoup moins savent défendre l’architecture de contrôle autour.
- En entreprise, une brique IA agentic est jugée sur son cloisonnement, sa traçabilité, son auditabilité et sa gouvernance autant que sur sa qualité de réponse.
- Les 7 questions listées ici ne sont pas des détails techniques. Elles correspondent au minimum de sérieux attendu par une DSI mature.
- L’enjeu n’est pas seulement de répondre aux questions. L’enjeu est d’avoir conçu le système pour que les réponses soient nettes, prouvables et tenables dans le temps.
Le marché commence à poser de meilleures questions à propos de l’IA. Et c’est une bonne nouvelle. Pas parce que cela ralentit les projets. Parce que cela force enfin les entreprises à sortir de la phase démonstrative.
Quand une brique IA agentic entre dans un processus réel, la question n’est plus seulement “est-ce que ça marche ?”. La vraie question devient “est-ce que ça tient ?”.
1. Cloisonnement du RAG au niveau du vector store entre tenants
Première question structurante : les données de retrieval sont-elles strictement séparées entre clients, business units ou espaces sensibles ?
Une architecture agentic sérieuse ne peut pas se contenter d’un discours vague du type : “les métadonnées filtrent les résultats”.
La vraie question DSI est plus précise :
- le cloisonnement est-il logique, physique ou hybride ?
- quelles garanties empêchent une fuite inter-tenant ?
- le filtrage est-il appliqué à tous les niveaux du pipeline ou seulement à la requête ?
- comment vérifie-t-on que les embeddings d’un tenant ne peuvent jamais être rappelés par un autre ?
Le minimum sérieux : séparation stricte des namespaces ou index par tenant, IAM et ACL alignés avec ce découpage, tests d’intrusion sur les filtres de retrieval et journalisation des accès.
Si la seule réponse est “on a mis des tags”, la DSI entend surtout : risque de fuite.
2. Détection et masquage de PII avant envoi au LLM
Deuxième sujet : que se passe-t-il avant qu’une donnée sensible parte dans le modèle ?
Une brique IA agentic bien cadrée doit savoir distinguer les données qu’on peut transmettre, celles qu’on doit pseudonymiser, celles qu’on doit bloquer et celles qu’on doit traiter localement.
La DSI attend des réponses concrètes sur les types de PII détectés, le moment de détection dans le pipeline, le mécanisme de redaction, la conservation éventuelle de la version non masquée et les règles de ré-identification quand elles sont nécessaires.
Le minimum sérieux : pipeline de détection avant envoi, règles explicites par catégorie, séparation entre logs techniques et données métier, conservation minimale et politique claire sur ce qui ne part jamais vers un fournisseur externe.
La sécurité IA n’est pas un add-on. C’est une architecture de contrôle.
Avant de promettre une brique agentic à un grand compte, il faut clarifier le cloisonnement, la circulation des données, les évaluations et la traçabilité réelle du système.
3. Hébergement des embeddings : interne ou API tierce, et pourquoi
Troisième question : où vit réellement la représentation vectorielle du savoir de l’entreprise ?
La bonne réponse n’est pas forcément “tout en interne”. La bonne réponse est une réponse argumentée.
Une DSI sérieuse veut comprendre où les embeddings sont calculés, où ils sont stockés, qui y a accès, quelle donnée source peut être approchée à partir d’eux et pourquoi ce choix d’hébergement est cohérent avec le niveau de sensibilité métier.
Le minimum sérieux : matrice de choix entre hébergement interne, cloud dédié ou service tiers, justification explicite par criticité, politique de rétention et d’effacement, et documentation sur la localisation des traitements.
4. Isolation des sessions pour éviter les fuites de contexte entre utilisateurs
Quatrième sujet : comment évite-t-on qu’un utilisateur hérite du contexte d’un autre ?
Dans les systèmes agentic, le danger ne vient pas seulement de la base documentaire. Il vient aussi de la mémoire de session, des caches, des résumés intermédiaires, des objets de travail partagés et des mécanismes de reprise.
La DSI attend des réponses concrètes sur le cycle de vie de la mémoire de session, la séparation des contextes par utilisateur, rôle ou organisation, l’expiration des sessions, le nettoyage des artefacts temporaires et la gestion des handoffs entre agents et opérateurs humains.
Le minimum sérieux : session IDs réellement isolés, aucune mémoire implicite partagée sans règle explicite, purge ou rotation des contextes temporaires, tests de non-contamination et traçabilité des handoffs.
5. Protection contre les attaques par model inversion
Cinquième question : que fait-on contre les attaques visant à extraire ou ré-approximer des informations sensibles à partir des interactions avec le modèle ?
Tout le monde n’a pas besoin d’une défense de laboratoire. Mais personne ne peut répondre sérieusement : “on n’est pas concerné”.
La DSI veut comprendre quels types d’attaques sont considérés plausibles, quelles limitations sont mises en place sur les requêtes et les sorties, quels garde-fous réduisent l’exposition sur les données sensibles et quels périmètres sont interdits à des modèles externes.
Le minimum sérieux : segmentation des cas d’usage sensibles, limitation des accès aux corpus critiques, hardening des prompts et sorties, monitoring des patterns anormaux d’extraction et revue régulière des scénarios d’abus.
6. Versioning et audit des prompt templates
Sixième sujet : qui peut modifier la logique de prompting, et comment le prouve-t-on ?
Dans beaucoup d’organisations, les prompts critiques vivent encore dans des fichiers, des interfaces ou des scripts sans vraie gouvernance. C’est intenable dès que la brique IA devient sensible.
Une DSI sérieuse pose très vite ces questions : où vivent les templates, qui peut les modifier, quelle validation précède une mise en production, peut-on reconstituer quel prompt a produit quel résultat et existe-t-il un audit trail complet ?
Le minimum sérieux : versioning formel des templates, workflow de review, traçabilité par version/date/auteur, mapping entre prompt, modèle, paramètres et sortie, et capacité de rollback propre.
Sans versioning, il n’y a pas d’industrialisation. Seulement une fragilité élégante.
7. Taux d’hallucination mesuré, framework d’évaluation documenté
Septième question, souvent la plus révélatrice : comment mesure-t-on la fiabilité réelle du système ?
Dire “ça marche bien” ne suffit pas. Une DSI demande de plus en plus sur quel jeu de cas on a évalué, quelle méthodologie a été utilisée, ce qu’on appelle hallucination dans ce contexte précis, quel est le taux observé par type de tâche et quelle stratégie de mitigation existe quand la confiance est faible.
Le minimum sérieux : définition opérationnelle des erreurs critiques, jeux de tests représentatifs, métriques suivies dans le temps, seuils d’acceptabilité par workflow et procédures d’escalade ou de blocage.
Le vrai niveau de maturité n’est pas d’avoir zéro erreur. C’est de savoir où elles apparaissent, à quelle fréquence et avec quel impact.
Ce que ces 7 questions révèlent vraiment
Ces 7 questions parlent de sécurité. Mais au fond, elles révèlent autre chose.
Elles révèlent si la brique IA agentic est encore une feature, ou si elle est déjà traitée comme un vrai système d’information.
Autrement dit, elles testent la qualité de l’architecture, la maturité de la gouvernance, la discipline sur la donnée, la capacité à auditer et la capacité à prouver.
Ce que toute DSI devrait exiger maintenant
Au minimum, une DSI devrait exiger quatre choses avant de considérer une brique IA agentic comme sérieuse :
1. Une doctrine de segmentation
Qu’est-ce qui peut aller vers quel modèle, dans quel contexte, avec quel niveau de sensibilité ?
2. Une doctrine de traçabilité
Qu’est-ce qu’on journalise, combien de temps, pour quel usage, avec quelle protection ?
3. Une doctrine d’évaluation
Comment mesure-t-on la qualité, la sécurité, les dérives et les risques ?
4. Une doctrine de réversibilité
Comment change-t-on de modèle, de fournisseur ou d’architecture sans casser toute la chaîne ?
Quick FAQ
Faut-il tout héberger en interne ?
Non. L’enjeu n’est pas de tout internaliser par principe. L’enjeu est de savoir justifier, par niveau de sensibilité, ce qui reste interne et ce qui peut être confié à un tiers.
Une petite équipe doit-elle traiter ces 7 sujets aussi tôt ?
Oui, si elle vise des clients structurés ou des usages critiques. Le niveau de sophistication de la réponse peut varier, pas l’existence des sujets.
Ces questions relèvent-elles seulement de la sécurité ?
Non. Elles touchent aussi à la gouvernance, à la conformité, à l’architecture, aux opérations et au go-to-market enterprise.
Le vrai enjeu est-il de bien répondre au questionnaire ?
Non. Le vrai enjeu est d’avoir conçu le système pour que les réponses soient simples, nettes et défendables.
Le sujet n’est pas seulement d’ajouter une brique IA. Le sujet est de savoir l’opérer sérieusement.
Si tu veux cadrer le cloisonnement, la gouvernance, les évaluations et la réversibilité d’une brique IA agentic, le bon point de départ reste un diagnostic d’architecture propre.