Tester une IA métier avec des données synthétiques : une recette pour RAG et Odoo
Avant de confier un processus à une IA, il faut pouvoir reproduire ses erreurs sans exposer les données de l’entreprise. Une publication Microsoft Research fournit un point de départ ; voici notre proposition de recette pour un RAG ou un agent métier.
1. Une méthode publiée, pas une offre à présumer
Le 30 octobre, Microsoft Research décrit des environnements d’entreprise synthétiques pour évaluer Copilot sans données clients. La méthode associe organisations simulées, génération de requêtes et contrôles de qualité. La publication décrit un dispositif interne ; elle ne démontre pas sa disponibilité pour votre entreprise.
2. Ce que cela change en Belgique et en France
Notre recommandation : déplacer une partie de la recette vers un laboratoire métier reproductible avant d’ouvrir les données de production. Une PME peut commencer avec des clients, commandes et documents fictifs. Une ETI, un grand groupe ou une administration devrait ajouter plusieurs services, rôles et historiques de décision. Le responsable métier définit la réponse attendue ; la DSI conserve la configuration et les résultats. Il s’agit d’une démarche de test proposée par Underside, sans promesse de gain chiffré.
3. Analyse Underside : tester les frontières du système
Pour un RAG, construire un corpus fictif avec deux versions contradictoires d’une procédure et une date d’entrée en vigueur. Demander la règle applicable et vérifier les citations, la date et la capacité à signaler une ambiguïté. Pour un agent connecté à Odoo Entreprise, préparer une base de test séparée : devis fictif, client homonyme, remise non autorisée et facture déjà validée. Vérifier que l’agent propose une action sans écrire lorsque son rôle ou la validation humaine manque. Ces scénarios sont nos propositions d’architecture, pas des intégrations annoncées par Microsoft.
4. Une recette mesurable et rejouable
Associer chaque scénario à un résultat attendu, un propriétaire et un critère bloquant : divulgation entre rôles, écriture interdite ou source absente. Inclure des cas où la bonne réponse est un refus ou une demande de clarification. Conserver versions du modèle, prompts, corpus, connecteurs, droits et journaux. Rejouer la même suite après chaque changement ; examiner les écarts avant de promouvoir la nouvelle configuration. Faire relire un échantillon par le métier pour éviter qu’un générateur et un évaluateur automatiques partagent les mêmes angles morts.
5. Confidentialité et souveraineté : garder un second contrôle
Un jeu fictif doit rester fictif : éviter de recopier tickets, noms ou contrats réels dans les instructions de génération. Documenter les sources et inspecter les sorties avant partage. Pour un déploiement local, cloud ou hybride, tester aussi les destinations réseau, la rétention des journaux et les accès d’administration. Une réussite sur données synthétiques ne prouve ni la conformité réglementaire ni le comportement sur toutes les données réelles. Prévoir ensuite un pilote limité et autorisé, avec suivi humain et procédure de retour arrière.
Priorité de recette : retenir un workflow, créer les données fictives et bloquer toute mise en production si les tests de droits ou de validation échouent.
Structurer une recette IA