La qualité des données compte. Mais en faire le préalable absolu à tout projet d’IA en entreprise est souvent une erreur de séquencement. Pour un agent, le vrai point de départ est un processus assez clair pour être exécuté, contrôlé et arrêté.
On entend partout la même consigne : avant de passer à l’intelligence artificielle, il faudrait nettoyer, structurer et gouverner toutes les données de l’entreprise.
Sur le principe, personne ne peut être contre de bonnes données. Mais utilisée comme condition préalable à toute expérimentation, cette idée devient l’une des meilleures façons de ne jamais commencer.
Une entreprise réelle ne dispose jamais d’une information parfaite. Elle fonctionne avec des CRM partiellement renseignés, des fichiers contradictoires, des décisions prises par e-mail, des procédures qui ne couvrent pas toutes les exceptions et un contexte encore détenu par quelques personnes.
Et pourtant, elle fonctionne. Les humains compensent : ils posent une question, cherchent dans un autre outil, confrontent deux sources, repèrent une incohérence ou demandent une validation avant d’agir.
Un agent IA correctement conçu peut reproduire une partie de cette discipline. Il ne rend pas une donnée fausse miraculeusement fiable. Il peut toutefois reconnaître une information manquante, consulter une source autorisée, signaler son incertitude et s’arrêter lorsqu’une décision dépasse son cadre.
Le débat utile n’est donc pas « faut-il de bonnes données ? ». Bien sûr que oui. La vraie question est : pour cette action précise, quelles données sont indispensables, lesquelles peuvent être recherchées et dans quel cas l’agent doit-il refuser d’agir ?
Qualité des données et IA : le faux préalable absolu
Il faut distinguer la qualité du patrimoine de données dans son ensemble de la qualité minimale nécessaire à une action donnée.
Une entreprise peut avoir besoin d’une gouvernance plus solide, d’un référentiel commun et d’une meilleure traçabilité. C’est notamment le rôle d’une architecture de type Salesforce Data 360 lorsqu’elle construit une source de vérité sans créer un nouveau silo.
Mais faut-il attendre que chaque fiche, chaque historique et chaque référentiel soient parfaits avant de tester un agent sur un processus étroit ? Pas nécessairement.
Pour préparer une relance commerciale, par exemple, l’agent n’a pas besoin que tout le CRM soit irréprochable. Il a besoin d’un identifiant fiable, d’un accès autorisé aux derniers échanges, d’une règle de déduplication, d’un statut clair et d’une validation avant envoi.
La « data readiness » n’est donc pas un état binaire. Elle dépend du cas d’usage, du niveau d’autonomie et du coût d’une erreur.
Pourquoi un agent IA ne fonctionne pas comme un modèle figé
Un système classique reçoit un jeu de données, exécute un calcul et produit une réponse. Dans ce cas, une donnée absente, fausse ou biaisée affecte directement le résultat. La formule « garbage in, garbage out » reste pertinente.
Un agent travaille, lui, dans une boucle outillée :
- observer la situation ;
- identifier ce qu’il sait et ce qui lui manque ;
- consulter les sources autorisées ;
- comparer les informations ;
- demander une précision si nécessaire ;
- proposer ou exécuter une action permise ;
- vérifier le résultat obtenu.
Le papier ReAct: Synergizing Reasoning and Acting in Language Models étudie précisément l’alternance entre raisonnement et actions. Dans les tâches expérimentales présentées, le raisonnement aide à suivre et mettre à jour un plan, tandis que les actions permettent d’interroger des sources externes et de recueillir de nouvelles informations.
Ce travail ne prouve pas qu’un agent résout tous les problèmes de données d’une entreprise. Il montre le mécanisme qui rend possible un comportement plus robuste qu’une réponse produite à partir d’un contexte figé.
Exemple : une relance commerciale avec un CRM incomplet
Imaginons qu’un CRM ne contienne pas la dernière activité d’une opportunité.
Un système qui considère le CRM comme une vérité absolue pourrait conclure qu’aucune relance n’a été effectuée et préparer un message inutile. Un collaborateur expérimenté vérifierait les e-mails envoyés, les rendez-vous, les notes de réunion et les brouillons. En cas d’ambiguïté, il demanderait une validation.
Un agent correctement encadré peut suivre la même démarche et conserver la trace des sources consultées, des contradictions détectées, de l’hypothèse retenue, de la validation obtenue et du résultat observé.
La robustesse ne vient donc pas seulement de la donnée. Elle vient du système construit autour de l’agent.
Le vrai frein à l’IA en entreprise est souvent le processus
Quand un projet d’IA bloque, l’explication « nos données ne sont pas assez propres » masque fréquemment des questions plus difficiles : quel résultat attend-on ? Qui valide une exception ? Quels droits accorde-t-on ? Comment détecte-t-on un doublon ? Comment mesure-t-on une tâche réellement terminée ?
Le NIST AI Risk Management Framework replace justement l’IA dans un système socio-technique plus large. Il articule gouvernance, contexte, mesure et gestion des risques ; il demande notamment de documenter les rôles, les objectifs, les tâches soutenues, la supervision humaine, les méthodes d’évaluation et le suivi en production.
La qualité et la représentativité des données y figurent bien, mais au sein d’un dispositif plus vaste.
1. L’entreprise ne sait pas définir ce qu’est une tâche terminée
« Aider les commerciaux » n’est pas un objectif opérationnel.
« Identifier chaque matin les opportunités sans prochaine action, vérifier les derniers échanges et préparer une relance pour validation » en est un.
Un agent a besoin d’un résultat observable, de règles de décision et de critères de réussite. Sans cela, il peut produire beaucoup de contenu sans créer de valeur.
2. Les droits d’action sont flous
Certaines entreprises donnent à l’IA accès à des documents, mais aucun moyen d’agir. Elles obtiennent un chatbot de plus.
D’autres accordent trop de droits, sans seuil de validation ni protection contre les doublons. Elles créent un risque opérationnel.
Il faut définir ce que l’agent peut lire, rapprocher, proposer, préparer en brouillon, exécuter seul, exécuter après validation ou ne jamais faire.
Le problème n’est pas seulement l’accès à la donnée. C’est le droit d’action associé à cette donnée.
3. Les exceptions n’ont pas de propriétaire
Que se passe-t-il lorsque deux sources se contredisent ? Qui valide une exception ? À partir de quel seuil une action doit-elle être approuvée ? Qui analyse un incident et qui peut modifier la règle ?
Sans réponse explicite, l’agent ne dispose pas d’un chemin sûr. Le blocage est organisationnel avant d’être technique.
4. Il n’existe aucune boucle de retour
Un agent utile ne devrait pas produire une réponse puis disparaître. Il doit pouvoir observer si l’action a fonctionné, recevoir un retour, corriger sa trajectoire et capitaliser sur les erreurs.
Dans Building effective agents, Anthropic décrit des agents qui utilisent des outils dans une boucle alimentée par le retour de l’environnement. L’article insiste aussi sur la simplicité initiale, les tests, les garde-fous, les conditions d’arrêt et les points de contrôle humains.
Sans boucle de retour, l’entreprise accumule des productions d’IA. Elle ne construit pas une capacité opérationnelle.
5. Le travail de l’agent n’est ni observable ni mesuré
Un agent doit laisser des preuves : sources utilisées, actions effectuées, erreurs rencontrées, validations obtenues et résultat final.
Il faut ensuite mesurer autre chose que le nombre de textes produits : temps réellement économisé, taux de tâches terminées, corrections humaines, erreurs ou doublons créés, incidents et résultat opérationnel.
Sans observabilité, il est impossible d’améliorer le système ou de déterminer le niveau de confiance qu’il mérite.
Quand la qualité des données reste non négociable
Dire que la donnée n’est pas toujours le premier frein ne signifie pas qu’elle devient secondaire.
Elle reste bloquante lorsque l’information indispensable n’existe nulle part, lorsque l’identité d’une personne n’est pas fiable ou lorsqu’une décision doit être exacte, reproductible et justifiable.
C’est particulièrement vrai pour :
- la paie et la comptabilité ;
- les droits d’accès et la cybersécurité ;
- les consentements et obligations réglementaires ;
- les opérations financières irréversibles ;
- les décisions sensibles affectant les droits ou la situation d’une personne ;
- les processus entièrement automatisés sans possibilité simple d’annulation.
Dans ces cas, l’agent ne doit pas « se débrouiller ». Il doit refuser d’agir, demander la donnée manquante ou imposer une validation humaine.
Il faut aussi distinguer une donnée ponctuellement absente d’un biais structurel. Un agent peut rechercher un numéro de commande oublié. Il ne peut pas corriger seul un historique commercial systématiquement biaisé ou une règle discriminatoire.
Cette nuance est au cœur de notre article sur Agentforce et la qualité des données avant le déploiement d’un agent IA : il ne s’agit pas de choisir entre gouvernance des données et capacité d’action, mais de calibrer les deux au risque réel du processus.
Comment lancer un agent IA sans attendre des données parfaites
Une démarche pragmatique tient en sept étapes.
1. Choisir un processus étroit, fréquent et réversible
Partez d’un travail réel, répétitif et coûteux, avec un résultat visible : préparer une relance, contrôler un dossier, rapprocher des pièces ou constituer un brouillon.
Si vous cherchez un point de départ dans Salesforce, consultez nos 10 cas d’usage concrets pour commencer avec Agentforce.
2. Définir le résultat et les critères d’arrêt
Décrivez ce qu’est une tâche réussie, les cas qui doivent être escaladés et les situations dans lesquelles l’agent doit s’arrêter.
3. Cartographier uniquement les preuves nécessaires
N’essayez pas de cartographier toutes les données de l’entreprise. Identifiez les quelques sources indispensables pour prendre une décision sur ce processus précis.
4. Définir les droits d’action
Lecture seule, préparation, validation obligatoire, exécution autonome ou interdiction : chaque niveau doit être explicite et proportionné au risque.
5. Traiter l’incertitude comme une sortie normale
L’agent doit pouvoir répondre : « il manque cette information », « ces deux sources se contredisent » ou « je ne peux pas agir sans validation ».
Un bon système ne masque pas l’incertitude. Il l’organise.
6. Construire les contrôles, les traces et le rollback
Prévoyez la déduplication, le journal des actions, la validation avant opération sensible, la conservation des sources et une méthode d’annulation.
7. Tester sur des cas réels et améliorer la donnée en continu
Testez les cas normaux, les informations incomplètes, les exceptions et les erreurs humaines. Mesurez les résultats, puis corrigez le processus et les données là où l’usage révèle une faiblesse réelle.
Un agent bien conçu ne se contente pas de composer avec une donnée imparfaite. Il peut signaler où elle manque, proposer une correction et améliorer progressivement le système.
L’usage de l’IA devient alors un moyen de prioriser la dette de données, plutôt que la récompense obtenue après un grand nettoyage sans fin.
De la « data readiness » à l’« operational readiness »
Dire « nos données ne sont pas prêtes » permet de repousser le sujet. Dire « nous ne savons pas encore qui est responsable, quelles actions nous autorisons, comment nous mesurons la réussite et comment nous traitons les exceptions » oblige l’entreprise à se transformer.
Le préalable à un agent IA n’est pas une base parfaite. C’est une organisation capable de dire :
- voici le résultat attendu ;
- voici les sources que tu peux consulter ;
- voici ce que tu as le droit de faire ;
- voici les preuves que tu dois conserver ;
- voici quand tu dois demander de l’aide ;
- voici comment nous saurons que tu as réussi.
La qualité des données compte. Mais en faire le commencement obligatoire de tout projet revient à penser l’IA comme un outil alimenté par une grande table propre.
Les agents changent le séquencement : ils peuvent chercher, confronter, demander, agir, observer et corriger, à condition d’être correctement outillés et encadrés.
Le véritable enjeu est donc l’operational readiness : la capacité de l’entreprise à confier une action à un système, à l’encadrer, à l’observer et à apprendre de son travail.
FAQ : données, gouvernance et agents IA
Faut-il nettoyer toutes les données avant de lancer un projet d’IA ?
Non. Il faut fiabiliser les données indispensables au cas d’usage choisi. Un processus étroit et réversible peut souvent démarrer avec un périmètre de données limité, à condition que l’agent sache rechercher, signaler une incertitude et s’arrêter.
Quelles données sont réellement indispensables à un agent IA ?
Celles sans lesquelles l’action serait fausse, non traçable ou dangereuse : identité, droits, statut de l’objet traité, preuves nécessaires à la décision et informations requises par la réglementation. Cette liste dépend du processus et du niveau d’autonomie.
Par quel processus commencer ?
Choisissez une tâche fréquente, assez étroite pour être décrite, dont le résultat est observable et dont l’erreur peut être corrigée. La préparation d’un brouillon ou le contrôle d’un dossier sont généralement plus adaptés qu’une décision irréversible.
Comment sécuriser un agent IA en entreprise ?
Définissez ses sources, ses droits, ses critères d’arrêt, les validations humaines, la déduplication, les journaux de preuve, les tests et le rollback. Mesurez ensuite les résultats en production et réduisez l’autonomie si les contrôles ne suffisent pas.
Passer d’une idée d’IA à un premier processus testable
Vous voulez identifier un processus assez étroit pour tester un agent IA sans attendre un grand nettoyage des données ? Cloud Girafe peut vous aider à cadrer le cas d’usage, les sources, les droits, les contrôles et les critères de réussite.
Parler de votre projet IA avec Cloud Girafe
Sources primaires et techniques
- ReAct: Synergizing Reasoning and Acting in Language Models, Shunyu Yao et al., version ICLR 2023. La source soutient le mécanisme d’alternance entre raisonnement, mise à jour d’un plan, gestion des exceptions et actions permettant de recueillir de l’information externe.
- NIST AI Risk Management Framework Core, AI RMF 1.0. Le cadre soutient la nécessité de définir gouvernance, contexte, rôles, supervision humaine, tâches, mesures, documentation et suivi en production.
- Building effective agents, Anthropic, 19 décembre 2024. La source décrit les agents comme des systèmes outillés en boucle, avec retours de l’environnement, tests, garde-fous, points de contrôle humains et conditions d’arrêt.
