Vos donnees d'entreprise sont-elles suffisantes pour l'IA ?

« Nos données ne sont pas parfaites. Pouvons-nous quand même démarrer avec l’IA ? » C’est la question la plus fréquente que nous entendons lors d’un premier entretien. La réponse rassurante : vos données n’ont pas besoin d’être parfaites. La réponse moins simple : elles doivent être suffisamment bonnes pour l’application concrète. Les exigences de qualité d’un assistant de recherche interne diffèrent fondamentalement de celles d’une évaluation de transactions financières. La bonne question n’est donc pas de savoir si vos données sont parfaites, mais si les données pertinentes sont suffisamment fiables pour cette tâche, avec un risque acceptable.

Commencez par une application concrète

Une évaluation générale de votre qualité de données s’étire indéfiniment et livre rarement une conclusion utile. Vous démarrez mieux avec un seul cas d’usage bien délimité : parcourir la documentation technique, extraire automatiquement des factures d’achat, établir des prévisions de vente, classer des réclamations, préparer des offres ou détecter des anomalies de production. Ce n’est qu’une fois cette application clairement définie que vous déterminez quelles données sont nécessaires et quelles exigences de qualité s’y appliquent. Ainsi vous liez les questions de données à un résultat business concret plutôt qu’à une ambition abstraite.

Sept questions pour évaluer vos données

Une fois l’application choisie, les sept questions ci-dessous vous aident à estimer rapidement si vos données peuvent la supporter. Nous posons les mêmes questions lors de chaque premier entretien d’analyse chez un client.

Les données nécessaires sont-elles disponibles ?

Dans beaucoup d’entreprises, les informations pertinentes sont dispersées entre les boîtes mail, les dossiers partagés, les fichiers Excel et les logiciels obsolètes. Ce n’est que lorsque ces informations sont accessibles de manière maîtrisée qu’une application IA peut réellement travailler avec. La disponibilité ne concerne donc pas seulement l’existence, mais aussi l’accessibilité.

L’information est-elle suffisamment complète ?

Les champs manquants ne sont pas toujours un problème. Ils le deviennent uniquement lorsque ces champs précis sont nécessaires à l’application. Une prévision de paiement avec des dates d’échéance manquantes a un impact important sur le résultat. Un résumé de procédures internes survit à quelques petites lacunes sans grand dommage.

Les données sont-elles correctes ?

Des codes produits erronés, des doublons client et des prix obsolètes conduisent inévitablement à des résultats erronés. L’IA ne rend pas fiables comme par magie des données mauvaises. Ce que l’IA fait bien : traiter les erreurs plus vite et à plus grande échelle. C’est précisément pourquoi vous examinez d’abord les données sources.

Tout le monde utilise-t-il les mêmes définitions ?

Qu’est-ce qu’un « client actif », précisément ? Quand appelez-vous une commande « en retard » ? Quels coûts appartiennent à quelle catégorie ? Dès que des services utilisent des définitions différentes, un système IA produit des conclusions contradictoires à partir des mêmes données sous-jacentes. Clarifier les définitions coûte généralement moins cher que d’en rattraper les conséquences plus tard.

Les données sont-elles suffisamment actuelles ?

Un assistant IA qui vous ressort des manuels vieux de trois ans donne des instructions techniquement correctes mais opérationnellement dépassées. Définissez donc comment les informations nouvelles, modifiées et retirées entrent dans le système, et à quelle vitesse.

L’origine est-elle traçable ?

Pour des décisions importantes, il doit être clair d’où provient l’information. L’utilisateur peut-il revenir à la source en un clic, ou la sortie reste-t-elle une boîte noire qu’il faut croire sur parole ? La traçabilité n’est pas un luxe, elle détermine si les gens osent utiliser le système.

Avez-vous le droit d’utiliser ces données à cette fin ?

Toutes les informations ne peuvent pas partir sur n’importe quelle plateforme IA. Vérifiez la confidentialité, les données personnelles, les accords contractuels, la propriété intellectuelle, les droits d’accès, les durées de conservation et les exigences de sécurité avant de charger un jeu de données dans un service externe. Cette question a sa place dans les premiers entretiens de sélection, pas dans la dernière semaine avant la mise en production.

Chaque application ne demande pas la même qualité de données

L’exigence de qualité dépend de ce que l’application fait avec la sortie. Grossièrement, les applications IA se répartissent en trois catégories, chacune avec sa propre barre.

Applications de support

Pensez à la recherche, au résumé ou à la rédaction d’une première version de document. Un collaborateur lit le résultat et corrige si nécessaire. Une certaine incomplétude est acceptable tant que les sources restent visibles et que l’utilisateur peut vérifier rapidement.

Applications opérationnelles

Ici les processus tournent avec elles : classification de tickets, planification, comptabilisations. Les données doivent être plus cohérentes et le système doit traiter clairement les exceptions, car il y a moins de contrôle humain entre l’entrée et l’action.

Applications décisionnelles

Les décisions financières, commerciales, RH ou de sécurité fondées sur une sortie IA imposent de hautes exigences : exactitude, explicabilité, contrôle, sécurité et une piste d’audit complète. Vous ne démarrez pas ici sans une analyse de risque approfondie et un plan clair pour l’intervention humaine.

Comment reconnaître une qualité de données insuffisante ?

Il existe des signaux clairs indiquant que votre gestion de données n’est pas encore prête pour certaines applications. Pensez aux listes fantômes dans Excel à côté des systèmes officiels, aux rapports qui donnent des chiffres KPI différents pour la même question, aux corrections manuelles sur les données produits ou clients, à l’absence de clarté sur la version actuelle, aux mêmes informations dans plusieurs systèmes en parallèle, aux champs importants remplis librement par les collaborateurs, aux exceptions qui ne vivent que dans les échanges de mails et à un historique difficile à retrouver. Ces signaux ne signifient pas que l’IA est impossible. Ils signifient que le risque augmente et qu’il faut planifier du travail supplémentaire avant de démarrer un cas d’usage.

Vous n’avez pas à nettoyer d’abord toutes les données

Le piège classique consiste à attendre que tout soit parfait. Ce moment arrive rarement, et pendant ce temps vous prenez du retard sur les entreprises qui bougent. Choisissez donc une approche ciblée : déterminez quelles données le cas d’usage nécessite vraiment, mesurez la qualité actuelle précisément de ces données, identifiez les erreurs qui ont le plus grand impact, corrigez uniquement ce qui est nécessaire à cette application, testez avec des exemples réalistes et surveillez la qualité pendant l’utilisation. Ainsi vous liez le nettoyage à un résultat business concret plutôt qu’à une opération de ménage sans fin que personne ne termine jamais.

Testez avec des exemples difficiles

Vous ne devez pas tester une application IA uniquement avec des données propres, complètes et soigneusement choisies. Utilisez aussi des documents incomplets, des formats déviants, des doublons, d’anciennes et de nouvelles versions côte à côte, des exceptions rares, des saisies erronées et des informations contradictoires provenant de sources différentes. Ce n’est qu’à ce moment-là que vous voyez comment l’application tient dans la réalité quotidienne de votre entreprise, où rien n’est aussi net que dans une démo.

Mesurez la qualité des données en impact business

Les pourcentages techniques de complétude et d’exactitude sont utiles, mais l’impact sur votre entreprise compte davantage. Une erreur dans un résultat de recherche interne relève d’une autre catégorie de poids qu’une erreur dans une proposition de paiement ou une instruction de production. Évaluez donc à quelle fréquence des erreurs surviennent, à quelle vitesse vous les détectez, combien de travail de correction elles génèrent, quels dommages financiers ou opérationnels elles causent et si un collaborateur peut intervenir à temps avant que l’erreur ne se propage dans le processus.

Conclusion

Vos données n’ont pas besoin d’être parfaites, mais elles doivent être adaptées à l’application et au risque associé. Choisissez un cas d’usage concret, déterminez quelles données sont critiques pour le résultat, et testez si ces données sont disponibles, correctes, actuelles et traçables. Une bonne donnée n’est pas une fin en soi. Elle est la condition d’un résultat business fiable avec l’IA.