Combien de données faut-il vraiment pour faire de l'IA en PME ?

Introduction

C'est probablement la phrase la plus entendue par les dirigeants de PME face à l'IA : "Il faut beaucoup de données pour que ça marche.". Souvent prononcée par des consultants, des intégrateurs, ou des prestataires qui veulent vendre un projet de "data lake" en amont d'un projet IA réel.

La vérité est plus nuancée. La quantité de données nécessaire dépend énormément du cas d'usage et de l'approche technique. Pour beaucoup de projets en PME, vous avez déjà bien plus de données qu'il n'en faut. Pour d'autres, aucune donnée nouvelle n'est nécessaire grâce aux modèles pré-entraînés. Et dans presque tous les cas, le vrai sujet n'est pas le volume, mais la qualité.

Cet article démêle ce qui est mythe, ce qui est vrai, et combien il faut vraiment selon votre cas d'usage.

Le mythe du "big data" comme prérequis IA

Le discours dominant des années 2015-2020 disait : "Pour faire de l'IA, il faut un data lake, des téraoctets de données, et 5 ans pour les nettoyer.". Cette approche existe encore dans certains grands groupes, et elle est largement responsable du mauvais ROI de beaucoup de projets IA des années 2010.

Cette logique est dépassée pour 3 raisons :

Les modèles pré-entraînés ont changé la donne. Les LLM, les modèles de vision, les modèles de reconnaissance vocale sont déjà entraînés sur des milliards d'exemples. Vous n'avez plus besoin de votre propre montagne de données pour bénéficier de leur puissance.

Beaucoup de cas d'usage en PME ne nécessitent pas d'apprentissage supervisé au sens classique. Du RAG, de la classification basée sur un LLM, de l'extraction d'information, de la génération de texte : tout ça peut marcher sans qu'on ait à fournir des milliers d'exemples étiquetés.

Les techniques modernes apprennent sur peu d'exemples. Le transfer learning, le few-shot learning et les approches LoRA permettent de spécialiser un modèle avec quelques centaines, voire quelques dizaines d'exemples seulement.

Combien il faut, en pratique, par type de projet

Voici des ordres de grandeur réalistes pour 2026 :

Aucune donnée propre nécessaire (0 exemple) :

• Utilisation d'un LLM générique (rédaction, résumé, traduction, brainstorming)
• Génération d'images via Midjourney, DALL-E ou Stable Diffusion
• Classification de texte avec un prompt zero-shot

Quelques dizaines d'exemples (10 à 100) :

• Few-shot learning pour adapter un LLM à votre vocabulaire métier
• Création d'un RAG sur quelques dizaines de documents internes
• Prompt engineering avancé avec exemples métier

Quelques centaines d'exemples (100 à 1 000) :

• Fine-tuning léger d'un LLM open-weight sur un domaine spécifique
• Modèle de classification sur catégorisation maison
• Détection d'anomalies sur données opérationnelles

Quelques milliers d'exemples (1 000 à 10 000) :

• Modèle de machine learning classique en production (régression, gradient boosting)
• RAG sur base documentaire moyenne
• Modèle prédictif sur données métier (churn, scoring, prévision)

Plusieurs dizaines de milliers d'exemples (10 000+) :

• Entraînement complet d'un modèle de deep learning custom
• Modèle de vision sur cas d'usage spécifique
• Agents IA complexes avec apprentissage par renforcement

Pour 80 % des cas d'usage en PME, on est dans les trois premières catégories. Aucune raison de geler un projet 2 ans pour collecter des données dont on n'aura pas besoin.

La qualité des données : le vrai sujet, bien plus que le volume

Si vous ne deviez retenir qu'une seule chose de cet article, ce serait celle-ci : en PME, le facteur limitant n'est presque jamais la quantité de données, c'est leur qualité. Le vieil adage de l'informatique reste plus vrai que jamais à l'ère de l'IA : garbage in, garbage out. Un modèle n'invente rien à partir de rien, il apprend ou raisonne à partir de ce que vous lui donnez. Des données médiocres produisent des résultats médiocres, quel que soit leur volume.

La quantité rassure, mais c'est un faux confort : multiplier par dix un jeu de données truffé d'erreurs ne fait que multiplier par dix les erreurs que le modèle apprend. À l'inverse, un petit jeu de données soigné amène très loin. La bonne question n'est donc pas "ai-je assez de données ?" mais "mes données sont-elles fiables ?". Concrètement, la qualité d'un jeu de données se mesure sur plusieurs dimensions, et chacune peut faire échouer un projet à elle seule :

L'exactitude. Les valeurs sont-elles justes ? Un CRM rempli à la va-vite, avec des montants faux ou des statuts jamais mis à jour, apprend à votre IA des réalités qui n'existent pas.

La complétude. Combien de champs vides, de lignes partielles ? Une donnée trouée à 40 % oblige le modèle à deviner, et il devine mal.

La fraîcheur. Un modèle entraîné sur des données de 2018 produira des résultats dépassés en 2026. Six mois de données récentes et représentatives valent souvent mieux que cinq ans d'historique périmé.

La représentativité. Vos données reflètent-elles vraiment le cas d'usage cible ? Si vous voulez prédire le churn de vos prospects, des données sur vos clients fidèles de longue date ne servent à rien — pire, elles biaisent le modèle.

La cohérence. Doublons, formats hétérogènes ("75001" d'un côté, "Paris 1er" de l'autre), unités mélangées : autant de pièges qui dégradent silencieusement les résultats sans qu'on s'en aperçoive.

L'étiquetage. Pour de l'apprentissage supervisé, c'est le point le plus critique. Un modèle apprend exactement ce que vous lui montrez. Si l'étiquetage est bâclé ou incohérent d'une personne à l'autre, le modèle apprend du bruit — et vous le rendra au centuple.

L'absence de biais. Des données historiques portent les biais de vos décisions passées. Une IA entraînée dessus ne se contente pas de les reproduire : elle les industrialise et les amplifie.

C'est exactement pour ça qu'un fichier Excel de 500 lignes propres, à jour et bien étiquetées vaut mille fois mieux qu'un data lake de 50 millions de lignes mal renseignées. La bonne nouvelle, c'est que la qualité, ça se travaille — et bien plus vite qu'on ne le croit. Un audit des quelques champs vraiment utiles à votre cas d'usage, un dédoublonnage, une mise à jour des données récentes : ces gestes simples suffisent souvent à transformer un jeu de données réputé "inexploitable" en base parfaitement utilisable pour un premier POC.

Les pièges qu'on voit en mission

En 5 ans de missions en PME et ETI, voici les écueils les plus fréquents en lien avec les données :

Le piège du "on attend d'avoir plus de données". Beaucoup de projets restent bloqués 18 mois "en attente du data lake". Pendant ce temps, un POC sur les données existantes aurait souvent suffi à valider la faisabilité.

Le piège du volume qui masque la qualité. On se rassure en accumulant des giga-octets, en oubliant que personne n'a vérifié si ces données étaient justes, à jour et cohérentes. Le volume ne compense jamais un défaut de qualité : il l'aggrave.

Le piège de l'export massif. On vous propose d'extraire 5 ans d'historique de votre ERP pour entraîner un modèle. En réalité, les 6 derniers mois sont souvent largement suffisants, et beaucoup plus représentatifs.

Le piège des données client externes. Acheter des données externes (LinkedIn, INSEE, BTP, etc.) coûte cher et est rarement utile pour des cas d'usage de PME. Vos données internes (CRM, ERP, échanges email, base produit) sont presque toujours plus pertinentes.

Le piège de la gouvernance data. Lancer un projet de gouvernance data avant un projet IA est une excellente manière de ne jamais faire d'IA. La bonne approche, c'est de démarrer un cas d'usage concret, et de structurer la donnée autour de ce besoin.

Notre recommandation pour démarrer

Pour une PME qui n'a jamais fait d'IA et se demande par où commencer :

Listez 3 cas d'usage candidats sans vous demander si vous avez les données. Décrivez juste le problème métier et la valeur attendue.

Pour chaque cas, regardez les données déjà disponibles dans vos outils existants (CRM, ERP, intranet, mails, comptes rendus). Vous serez surpris. Au passage, évaluez honnêtement leur qualité : sont-elles à jour, complètes, cohérentes ?

Démarrez par le cas où les données existantes suffisent pour un POC, même imparfaites. Mieux vaut prototyper avec ce qu'on a que d'attendre la perfection — à condition de rester lucide sur les défauts de vos données.

Utilisez le POC pour identifier les vraies lacunes data et structurer la collecte, plutôt que de spéculer en amont.

C'est exactement la logique de notre diagnostic IA hIAppy Vision : on cadre un cas d'usage à partir de votre réalité de PME, pas d'un idéal de big data corporate. Voir aussi notre projet IA en 9 étapes.

Ce qu'il faut retenir

La quantité de données n'est presque jamais le facteur limitant en PME. Pour la majorité des cas d'usage, vous avez largement assez de données pour démarrer aujourd'hui. Ce qui fait la différence, ce n'est pas le volume, c'est la qualité : des données exactes, à jour, représentatives et bien étiquetées. C'est là que se joue la réussite d'un projet, bien plus que dans le nombre de lignes.

Si un prestataire vous explique que vous ne pouvez pas faire d'IA tant que vous n'avez pas un data lake, demandez-lui un POC sur les données existantes. La réponse à sa proposition vous dira beaucoup sur la sincérité de sa démarche.