De nombreuses organisations disposent déjà d’un prototype capable de résumer un document, de répondre à une question ou de générer du SQL. Le passage à l’échelle révèle pourtant une autre réalité : l’IA dépend moins de la seule qualité du modèle que de la qualité du système Data auquel elle est raccordée.
À retenir pour la DSI
- Commencer par une décision ou un processus métier, pas par un modèle.
- Évaluer les données, les droits, la fraîcheur et la traçabilité avant le prototype.
- Prévoir l’observabilité, l’évaluation et le contrôle des coûts dès la conception.
- Différencier les réponses assistées, les recommandations et les décisions automatisées.
- Mesurer la valeur en production, pas uniquement la qualité d’une démonstration.
1. Le cas d’usage produit-il une valeur mesurable ?
Une demande telle que « créer un chatbot sur nos données » ne suffit pas. La DSI doit pouvoir relier la solution à une action : réduire le temps de recherche d’une procédure, accélérer une première analyse, diminuer le nombre d’incidents mal qualifiés, améliorer la détection d’anomalies ou fiabiliser une décision récurrente.
Le cas d’usage doit préciser les utilisateurs, la fréquence, le coût actuel, le niveau de confiance nécessaire et le traitement prévu lorsque la réponse est incertaine.
| Question | Signal favorable | Signal d’alerte |
|---|---|---|
| Quel résultat change ? | Un délai, un coût ou un risque mesurable | Une promesse générique de productivité |
| Qui agit sur la réponse ? | Un rôle et un processus identifiés | Un public indéfini |
| Quel est le coût de l’erreur ? | Connu et couvert par un contrôle | Non évalué |
2. Les données sont-elles réellement exploitables ?
La disponibilité technique ne garantit pas l’utilisabilité. Une solution IA doit savoir quelles sources sont autorisées, quelle version d’un document fait foi, à quelle date un indicateur est valide et qui est responsable de sa définition.
Pour un Data Copilot, la couche sémantique est déterminante. Sans définitions partagées, une question simple comme « quel est le revenu client ? » peut produire plusieurs réponses techniquement correctes et métier incompatibles.
Points de contrôle
- catalogue des sources et propriétaires ;
- qualité, fraîcheur et historique ;
- dictionnaire des indicateurs ;
- classification de sensibilité ;
- droits d’usage et de réutilisation ;
- lineage jusqu’à la réponse présentée.
3. Le modèle respecte-t-il les règles d’accès existantes ?
L’IA ne doit pas devenir un raccourci autour des contrôles de la plateforme. L’autorisation doit être appliquée au moment de la récupération des données, de la génération de la requête et de la restitution. Une réponse synthétique peut révéler une information sensible même si le document source n’est jamais affiché.
Il faut également traiter les injections de prompt, l’exfiltration indirecte, la conservation des échanges, l’utilisation des données par le fournisseur et les droits des administrateurs.
4. L’architecture est-elle conçue pour l’évaluation et l’évolution ?
Une architecture robuste sépare généralement l’expérience utilisateur, l’orchestration, la recherche, les modèles, les politiques de sécurité, les outils d’évaluation et les systèmes de référence. Cette séparation permet de changer un composant sans reconstruire l’ensemble.
Le choix entre modèle hébergé, service managé ou déploiement privé dépend de la sensibilité des données, de la latence, du volume, des compétences et du niveau de contrôle attendu. Il n’existe pas de réponse unique.
Capacités à prévoir
- journalisation des entrées, sources, décisions et sorties ;
- jeu d’évaluation représentatif des usages ;
- routage entre modèles selon le besoin ;
- limites de consommation et quotas ;
- gestion des versions des prompts et des connaissances ;
- mécanisme de retour utilisateur et de correction.
5. Comment la qualité sera-t-elle mesurée ?
La qualité d’un système génératif ne se résume pas à un score unique. Une DSI doit distinguer la pertinence de la réponse, la fidélité aux sources, la complétude, la sécurité, la latence, le coût et l’utilité réelle.
Le jeu d’évaluation doit inclure les questions fréquentes, les cas difficiles, les demandes ambiguës, les informations absentes et les tentatives de contournement. Les résultats sont comparés lors de chaque évolution importante.
6. Qui exploite le service ?
Le passage en production crée de nouvelles responsabilités. Qui valide une source ? Qui traite un signalement ? Qui décide qu’une réponse nécessite un contrôle humain ? Qui suit la consommation ? Qui arbitre une évolution du modèle ?
Un modèle opérationnel minimal associe un owner métier, un owner produit, la plateforme Data, la sécurité, le juridique ou la conformité lorsque nécessaire, et une capacité d’exploitation.
7. Les coûts sont-ils reliés à l’usage et à la valeur ?
Les coûts d’une solution IA proviennent des modèles, des recherches, du stockage, de l’observabilité, des traitements de préparation et du support. Le prix unitaire d’un appel ne donne donc qu’une vision partielle.
La DSI doit pouvoir attribuer la consommation à un produit, un domaine ou un parcours, définir des budgets et suivre le coût par résultat utile : dossier traité, question résolue, incident qualifié ou heure économisée.
8. Le niveau d’autonomie est-il adapté au risque ?
Il est utile de distinguer trois niveaux :
- Assistance : l’utilisateur reste responsable et voit les sources.
- Recommandation : le système propose une action soumise à validation.
- Automatisation : le système déclenche l’action dans des limites définies.
Plus l’autonomie augmente, plus les contrôles, la réversibilité et la supervision doivent être exigeants.
9. Une trajectoire en trois étapes
Étape 1 - prouver l’utilité
Un périmètre limité, des données identifiées, un jeu d’évaluation et un utilisateur réel. Le résultat attendu est une décision documentée, pas une démonstration spectaculaire.
Étape 2 - sécuriser le service
Intégrer les accès, l’observabilité, les politiques, la gestion des incidents, les coûts et le support.
Étape 3 - industrialiser le portefeuille
Créer des composants partagés, un processus de sélection des cas d’usage, des standards d’évaluation et une gouvernance de la consommation.
10. La checklist de décision
- Le problème et l’indicateur de valeur sont explicités.
- Les utilisateurs et le processus cible sont connus.
- Les sources de référence et leurs propriétaires sont identifiés.
- Les droits sont appliqués jusqu’à la réponse.
- Un jeu d’évaluation couvre les usages et les risques.
- Le coût complet peut être attribué.
- Les responsabilités d’exploitation sont définies.
- Une procédure existe pour les erreurs et les demandes sensibles.
- La solution peut évoluer sans dépendre d’un seul composant.
- La décision d’industrialisation s’appuie sur des résultats observés.
Une plateforme prête pour l’IA n’est pas celle qui possède le plus de modèles. C’est celle qui peut transformer un cas d’usage en service fiable, gouverné et mesurable.