Données pour un projet IA : qualité, accès, sécurité et gouvernance

Les données d’un projet IA ne sont pas un simple carburant qu’il suffirait de verser dans un modèle. Elles définissent ce que le système peut apprendre, retrouver, comparer ou générer. Leur qualité influence la performance ; leurs droits d’usage influencent la légalité ; leur organisation influence le coût ; leurs autorisations influencent la sécurité.

Une entreprise peut lancer certains usages d’IA générative à partir de documents, de courriels et de PDF sans posséder un entrepôt de données sophistiqué. Cela ne dispense pas de trier les sources, d’identifier les versions valides et de contrôler qui peut voir quoi. La préparation doit être proportionnée au projet, mais elle ne peut pas être supprimée.

En bref

Inventoriez les sources, responsables, formats, volumes, fréquences et niveaux de sensibilité.
Évaluez les données sur un échantillon avant de promettre un résultat ou un budget ferme.
Distinguez données d’apprentissage, de configuration, de test et de production.
Conservez les droits d’accès de la source jusqu’à la réponse produite par l’IA.
Organisez la mise à jour, la suppression, la traçabilité et la surveillance après le lancement.

De quelles données un projet IA a-t-il besoin ?

La réponse dépend du cas d’usage. Un assistant RAG exploite une documentation et ses métadonnées. Une prévision utilise un historique de ventes, de stocks et de variables explicatives. Une classification de demandes s’appuie sur des exemples catégorisés. Une vision industrielle nécessite des images représentatives des situations réelles.

Commencez par le résultat attendu, puis remontez vers les sources. Pour « proposer une réponse à un ticket », il peut falloir le message, la catégorie, le produit concerné, la documentation, l’historique autorisé et l’issue du dossier. Pour « prédire une panne », les données de capteurs ne suffisent pas si les interventions et causes confirmées ne sont jamais enregistrées.

Une cartographie des cas d’usage IA aide à éviter la collecte massive de données « au cas où ».

Construire un inventaire exploitable

Pour chaque source, notez :

son propriétaire métier et son administrateur technique ;
son emplacement et son format ;
son volume actuel et sa croissance ;
sa fréquence de mise à jour ;
les catégories de données personnelles ou confidentielles ;
les règles d’accès, de conservation et de suppression ;
les défauts connus et la source de référence en cas de conflit.

Cet inventaire révèle les dépendances. Une documentation peut être riche mais dispersée entre un lecteur réseau, une GED, des courriels et les ordinateurs des experts. Le travail ne consiste pas seulement à connecter des fichiers ; il faut décider lesquels font autorité.

Mesurer la qualité en fonction de l’usage

Une donnée n’est pas « bonne » dans l’absolu. Elle est adaptée ou non à une tâche. Examinez plusieurs dimensions.

L’exactitude indique si l’information correspond à la réalité. La complétude mesure les champs ou situations manquants. La fraîcheur vérifie que la source est encore valable. La cohérence repère les contradictions. La représentativité contrôle que les données couvrent les utilisateurs et circonstances futurs.

Pour une base documentaire, ajoutez la lisibilité des scans, la structure des fichiers, la présence de titres, les versions et les métadonnées. Pour un historique, vérifiez les changements de règles et les événements exceptionnels.

Ne nettoyez pas tout le système d’information avant de commencer. Traitez d’abord le périmètre nécessaire au POC IA, tout en documentant ce qui devra être industrialisé.

Données d’apprentissage, RAG et instructions : ne pas confondre

L’entraînement modifie les paramètres d’un modèle à partir d’un corpus. Un ajustement spécialisé, ou fine-tuning, adapte le comportement à des exemples. La RAG recherche des passages dans une base au moment de la question et les fournit au modèle. Les instructions décrivent le rôle et les règles du système.

Ces approches répondent à des besoins différents. Pour actualiser une procédure qui change chaque semaine et citer sa source, un RAG en entreprise est souvent plus adapté qu’un nouvel entraînement. Pour imposer un format stable ou un style, des exemples et des instructions peuvent suffire.

Demandez au prestataire quelles données entrent dans chaque mécanisme et comment elles peuvent être corrigées ou supprimées.

Créer un jeu de test indépendant

Le jeu de test représente les situations auxquelles la solution sera confrontée : cas courants, rares, difficiles, incomplets et interdits. Il doit rester distinct des exemples utilisés pour configurer ou ajuster le système.

Chaque cas possède une référence ou une grille d’évaluation. Pour une extraction, les valeurs sont connues. Pour une réponse générative, les experts vérifient l’exactitude, les sources, l’utilité et la conduite en cas d’incertitude.

Versionnez ce jeu. Il devient un actif de l’entreprise : il permet de comparer un modèle, une nouvelle version ou un autre prestataire sans repartir de zéro.

RGPD : définir la finalité et les rôles

Lorsqu’un projet traite des données personnelles, il faut déterminer la finalité, la base légale, les personnes concernées, les durées et les droits. La CNIL rappelle qu’un système d’IA ne peut pas être développé ou utilisé avec des données collectées illégalement.

Clarifiez qui est responsable de traitement, sous-traitant et éventuellement responsable conjoint. Identifiez les fournisseurs de modèles, d’hébergement, de base de données et d’annotation. Vérifiez les transferts hors de l’Espace économique européen et les conditions de réutilisation des données.

La minimisation reste essentielle : ne transmettez pas l’intégralité d’un dossier client si deux champs suffisent. L’anonymisation ou la pseudonymisation peut réduire le risque, à condition d’être correctement réalisée.

Préserver les droits d’accès de bout en bout

Un utilisateur ne doit pas obtenir par l’assistant une information qu’il ne pourrait pas ouvrir dans la source. Cette règle devient délicate lorsqu’un index réunit des documents de plusieurs services.

Les autorisations peuvent être propagées lors de l’indexation ou contrôlées au moment de la requête. Le choix dépend des outils et des volumes. Dans tous les cas, testez les accès négatifs : un commercial peut-il faire apparaître un document RH par une question détournée ?

Pour un agent capable d’agir, séparez le droit de lire, de préparer et d’exécuter. Les contrôles critiques doivent rester hors du modèle, dans des composants déterministes et auditables.

Sécuriser les flux et les environnements

Cartographiez le trajet d’une donnée : poste utilisateur, interface, serveur, modèle, journaux, sauvegardes et outils de supervision. Une politique de confidentialité ne suffit pas si des contenus sensibles sont recopiés dans des logs ou un environnement de test partagé.

Prévoyez chiffrement, authentification, moindre privilège, séparation des environnements, rotation des secrets, journalisation et suppression. Pour les applications génératives, testez l’injection de prompt, l’exfiltration et les sorties qui pourraient être interprétées comme des commandes.

Le guide AI Act, RGPD et sécurité réunit les principaux points de vigilance.

Organiser l’alimentation en production

Une solution n’est pas terminée lorsque le premier corpus est chargé. Qui ajoute les nouveaux documents ? Comment une version obsolète est-elle retirée ? Quel délai sépare la modification de la source et sa disponibilité dans l’assistant ? Comment une personne exerce-t-elle son droit de rectification ou d’effacement ?

Définissez des responsables, des fréquences, des contrôles et des alertes. Surveillez le volume, la fraîcheur, les erreurs d’indexation et la qualité des réponses. Conservez la capacité de revenir à une version précédente lorsque l’alimentation crée une régression.

Faut-il créer un « data lake » avant de faire de l’IA ?

Pas nécessairement. Une architecture centralisée peut être utile pour plusieurs projets analytiques, mais elle ne doit pas devenir un préalable abstrait. Un projet limité peut s’appuyer sur quelques sources correctement gouvernées.

En revanche, si chaque nouveau cas exige de reconstruire les mêmes connecteurs, droits et contrôles, une plateforme de données commune devient rationnelle. L’audit IA de l’entreprise doit faire apparaître ces mutualisations.

Les erreurs à éviter

Ne transmettez pas des données réelles à plusieurs candidats avant d’avoir validé la confidentialité. Ne supposez pas que tous les fichiers d’un dossier sont valides. Ne mélangez pas le jeu de test et les exemples de mise au point. Ne donnez pas à l’agent plus d’accès que l’utilisateur.

Enfin, ne réduisez pas la gouvernance à un nettoyage initial. Les données, les modèles et les processus évoluent. La responsabilité doit survivre à la fin de la mission du prestataire.

Questions fréquentes sur les données d’un projet IA

Peut-on utiliser des PDF et des courriels ?

Oui. Les IA génératives travaillent avec des données non structurées, mais les fichiers doivent être sélectionnés, lisibles, actualisés et associés aux bonnes autorisations.

Faut-il beaucoup de données ?

Pas pour tous les projets. Un RAG peut créer de la valeur avec une documentation limitée. Un modèle prédictif ou une détection spécifique demande souvent un historique plus important et représentatif.

Un fournisseur peut-il utiliser nos données pour entraîner ses modèles ?

Cela dépend du service et du contrat. Vérifiez les conditions de l’offre professionnelle, les paramètres, les sous-traitants et les engagements écrits. N’extrapolez pas à partir d’une version grand public.

Sources utiles

Faites évaluer les données de votre projet

Indiquez les sources, les volumes, les formats, les utilisateurs et les contraintes de confidentialité. Codimiq aide à qualifier la demande avant de la transmettre à des spécialistes data, RAG, automatisation ou développement IA.

Décrire mon projet IA