Quand on lance un projet de machine learning, la première question opérationnelle n’est pas « quel algorithme choisir ? » mais « d’où viennent les données d’entraînement ? ». La qualité, la diversité et la conformité réglementaire du corpus conditionnent directement les performances du modèle. Les sources de collecte de données en IA se répartissent en grandes familles, chacune avec ses contraintes terrain que les équipes doivent arbitrer dès la phase de cadrage.
Scraping web et données accessibles en ligne : ce que l’AI Act change concrètement
Le réflexe le plus courant pour constituer un jeu de données massif reste l’extraction automatisée depuis le web. On collecte du texte, des images ou des métadonnées sur des sites publics, des forums, des réseaux sociaux. La scalabilité est forte, le coût initial faible.
A voir aussi : Puis-je utiliser Chatgpt comme traducteur ?
Le problème, c’est que ce levier est désormais encadré de manière beaucoup plus stricte. L’AI Act européen (Règlement UE 2024/1689), entré en vigueur le 1er août 2024, impose aux fournisseurs de modèles d’IA à usage général de documenter la provenance de chaque source d’entraînement : origine, dates de collecte, catégories de données, tests de biais. Les exigences sur ces modèles s’appliquent depuis août 2025.
En parallèle, l’EDPB a publié des lignes directrices spécifiques sur le web scraping pour l’IA, articulant le RGPD et l’AI Act. Ces règles s’appliquent dès la constitution du corpus, pas seulement à l’entraînement. Concrètement, on ne peut plus se contenter de lancer un crawler sans vérifier la base légale du traitement ni la nature des données personnelles aspirées.
A découvrir également : Quelle est l'influence des réseaux sociaux ?
Pour les équipes, cela signifie qu’un pipeline de scraping doit intégrer dès le départ un module de filtrage (données personnelles, contenus protégés par le droit d’auteur) et un journal de traçabilité exploitable en cas d’audit. Les métadonnées de collecte deviennent elles-mêmes une source d’information que le projet doit produire et maintenir.
Données propriétaires d’entreprise : le levier sous-estimé
Les données internes (CRM, logs applicatifs, historiques de transactions, tickets support) représentent souvent le corpus le plus pertinent pour un cas d’usage métier. Elles reflètent les comportements réels des utilisateurs ou des processus, avec un niveau de contexte que les données publiques ne fournissent pas.
Le coût de collecte est faible puisque les données existent déjà. Le vrai investissement porte sur leur structuration et leur nettoyage. On rencontre régulièrement des champs mal renseignés, des formats hétérogènes entre filiales, des doublons non détectés. La qualité des données internes détermine la fiabilité du modèle bien plus que leur volume.
Autre point de vigilance : la conformité. Même si les données sont « les nôtres », les réutiliser pour entraîner un modèle IA peut nécessiter une nouvelle base légale au sens du RGPD, surtout si elles contiennent des données personnelles collectées pour une finalité différente.
Données synthétiques : générer ce qu’on ne peut pas collecter
Quand le corpus réel est trop petit, biaisé ou trop sensible pour être exploité directement, la génération de données synthétiques offre une alternative concrète. On utilise des modèles génératifs pour produire des jeux de données artificiels qui reproduisent les propriétés statistiques du corpus original sans exposer d’information réelle.
Ce levier est particulièrement utile dans les secteurs réglementés (santé, finance, assurance) où l’accès aux données personnelles est restreint. Les données synthétiques permettent d’entraîner et de tester des modèles sans risquer de violation de confidentialité.
Les retours varient sur ce point : la qualité du modèle synthétique dépend fortement de celle du corpus source. Si le jeu de données original contient des biais, le générateur les reproduira. Il faut donc coupler la génération à des tests de biais et de représentativité avant de valider le corpus.
Jeux de données publics et crowdsourcing : arbitrer coût contre contrôle
Les jeux de données prêts à l’emploi (datasets ouverts sur des plateformes académiques ou institutionnelles) permettent de démarrer rapidement un projet sans investir dans la collecte. Pour le prototypage ou la recherche, c’est souvent le chemin le plus court.
La limite est double :
- Le contrôle qualité est limité : on hérite des biais, des erreurs d’annotation et des lacunes du producteur initial sans toujours pouvoir les auditer en profondeur
- La personnalisation est faible : le jeu de données ne couvre pas forcément le cas d’usage métier, ce qui oblige à compléter avec d’autres sources
- La conformité réglementaire n’est pas garantie : un dataset ouvert ne signifie pas que les données ont été collectées dans le respect du RGPD, surtout si elles contiennent des données personnelles ou des contenus sous droit d’auteur
Le crowdsourcing (collecte participative via des contributeurs humains) répond au besoin de personnalisation. On définit des tâches précises (annotation d’images, transcription audio, classification de texte) et on recrute des contributeurs à grande échelle. Le volume monte vite, mais la qualité exige un processus de vérification rigoureux avec des mécanismes de contrôle croisé entre annotateurs.
Annotation et labellisation : la couche invisible qui conditionne tout
Quelle que soit la source, les données brutes ne suffisent pas pour l’apprentissage supervisé. L’étape de labellisation (attribuer une étiquette, une catégorie ou un cadre à chaque donnée) conditionne directement ce que le modèle apprend.
On peut gérer l’annotation en interne, l’externaliser vers des prestataires spécialisés, ou combiner annotation humaine et pré-annotation automatisée. Chaque option implique un arbitrage entre coût, rapidité et précision.
- L’annotation en interne offre un contrôle maximal sur la qualité et la cohérence, mais elle mobilise des ressources métier rares
- L’externalisation permet de passer à l’échelle rapidement, au prix d’un effort de spécification et de contrôle qualité plus lourd
- La pré-annotation par un modèle existant accélère le processus, à condition qu’un humain valide systématiquement les résultats pour éviter de propager des erreurs
L’AI Act renforce cette exigence : pour les systèmes à haut risque, la documentation technique doit couvrir les processus d’annotation et démontrer que les biais ont été identifiés et traités. Les obligations les plus lourdes sur ce volet deviennent pleinement opposables en août 2026.
Le choix des sources de collecte n’est jamais purement technique. Il engage la conformité réglementaire du projet, la qualité du modèle final et la capacité des équipes à maintenir le corpus dans le temps. Avec l’entrée en application progressive de l’AI Act, la traçabilité des données d’entraînement passe du statut de bonne pratique à celui d’obligation documentée.
