Données métier et IA : préparer un corpus utile dans une PME

Une PME n’a pas besoin de verser toutes ses archives dans un outil d’intelligence artificielle. Elle doit d’abord isoler les données utiles à une tâche précise, vérifier leur qualité, protéger ce qui doit l’être et préparer un test qui permet de juger le résultat.

La bonne unité de départ n’est donc pas « toutes nos données ». C’est un corpus limité, documenté et relié à une décision métier.

Cette distinction devient concrète dans l’industrie. Une conférence annoncée le 10 septembre 2026 à Strasbourg par La French Tech Est cite des devis, plans, fiches de fabrication, retours terrain et savoir-faire transmis par les équipes. Ces matières peuvent soutenir un projet d’IA. Leur ancienneté ou leur volume ne garantit pourtant ni leur pertinence ni leur exploitabilité.

Des archives ne forment pas encore un corpus

Un dossier partagé peut contenir plusieurs versions du même document, des règles devenues fausses, des scans difficiles à lire et des informations personnelles sans rapport avec le projet. Un devis peut utiliser une ancienne nomenclature. Une fiche de fabrication peut décrire une exception devenue la règle. Un retour terrain peut être exact sans être suffisamment contextualisé pour être réutilisé.

Brancher un modèle sur cet ensemble ne répare pas ces contradictions. Le système peut au contraire les restituer avec une formulation convaincante.

Un corpus utile doit permettre de répondre à quatre questions :

• quelle tâche doit-il aider à accomplir ;
• qui possède et maintient les sources ;
• comment distinguer une information valide d’une information obsolète ;
• comment vérifier qu’une réponse ou une action est acceptable.

Sans ces réponses, le projet reste une démonstration technique.

Commencer par une décision métier

Le premier atelier ne porte pas sur le choix du modèle. Il porte sur une situation répétitive et vérifiable.

Par exemple : retrouver la procédure applicable à une référence, préparer une réponse technique à faire valider, repérer les dossiers incomplets ou rapprocher une demande entrante d’une nomenclature interne.

Pour cadrer le cas, écrivez une phrase simple :

À partir de quelles sources, le système doit-il produire quelle sortie, pour quelle personne, avant quelle validation ?

Cette phrase fixe les limites. Elle évite d’aspirer des années de documents alors que trois familles de fiches suffisent peut-être au premier test. Elle montre aussi le coût d’une erreur. Une mauvaise suggestion interne et une instruction envoyée directement à un atelier ne réclament pas le même contrôle.

Une méthode en six étapes

1. Cartographier les sources réelles

Listez les emplacements, pas seulement les logiciels : dossiers réseau, messageries, ERP, CRM, tableurs, classeurs papier, plans, photos, bases techniques et mémoire de personnes clés.

Pour chaque source, notez son propriétaire, son format, sa période de validité, ses droits d’accès et la manière dont elle est mise à jour. Une source sans responsable ou sans date de référence doit être considérée comme incertaine jusqu’à vérification.

2. Examiner un échantillon avant d’exporter

Prenez un petit ensemble représentatif de cas simples, difficiles, récents et anciens. Ouvrez réellement les fichiers. Cherchez les doublons, les champs vides, les unités implicites, les noms incohérents, les versions concurrentes et les documents illisibles.

Ce contrôle donne une vision plus honnête que le nombre total de fichiers. Il permet aussi d’estimer le travail humain nécessaire : arbitrer deux règles contradictoires, convertir un scan, compléter une référence ou exclure une période devenue inutile.

3. Sélectionner selon la finalité

Conservez uniquement ce qui contribue à la tâche choisie. La CNIL rappelle que les données personnelles doivent être adéquates, pertinentes et limitées à ce qui est nécessaire. Elle recommande aussi d’examiner les risques de biais, la pseudonymisation, le masquage et les possibilités de suppression.

Cette règle est utile au-delà de la conformité. Moins de données inutiles signifie moins de bruit à nettoyer, moins d’accès à ouvrir et moins d’informations à exposer en cas d’erreur de configuration.

4. Ajouter le contexte qui manque aux fichiers

Une archive contient rarement toute la logique métier. Il faut souvent lui joindre un glossaire, la date d’effet, la famille de produits concernée, les exceptions, la personne qui a validé la règle et le lien vers la source originale.

Cette couche de contexte évite de confondre une note exploratoire avec une procédure active. Elle permet également de citer l’origine d’une réponse au lieu de demander aux équipes de faire confiance à une sortie sans preuve.

5. Séparer préparation, test et production

Le corpus de travail ne doit pas servir simultanément à construire le système et à prouver qu’il fonctionne. Conservez des cas de contrôle qui n’ont pas été utilisés pendant la préparation.

Pour chaque cas, définissez la réponse attendue, les sources acceptables et les erreurs interdites. Le cadre de gestion des risques IA du NIST insiste sur la documentation, la mesure et l’évaluation des données et du système dans son contexte d’usage. Pour une PME, cela peut devenir une grille courte : réponse exacte, source retrouvable, absence d’invention, respect des droits d’accès et demande de validation quand l’information manque.

6. Nommer un responsable du corpus

Un corpus vieillit. Une procédure change. Une gamme disparaît. Un capteur ou un logiciel modifie la forme des données reçues.

Il faut donc une personne responsable des ajouts, retraits, corrections et droits d’accès. Chaque changement important doit déclencher une nouvelle série de tests. Sans cette maintenance, la qualité mesurée au lancement ne dit plus grand-chose quelques mois plus tard.

Choisir l’architecture après le corpus

Une fois les sources clarifiées, le choix technique devient plus simple.

Un assistant documentaire peut rechercher des passages dans des procédures tenues à jour et présenter leurs sources à un salarié. Une automatisation peut lire des données structurées, appliquer une règle limitée puis demander une validation. Un entraînement ou un ajustement spécifique du modèle ne se justifie que si le besoin, les exemples et le protocole d’évaluation le demandent réellement.

Cette séquence évite une erreur courante : choisir d’abord un outil, puis chercher un problème et des données capables de le nourrir.

Le premier livrable utile

Avant un prototype, une PME devrait pouvoir réunir cinq éléments :

• la phrase qui décrit la tâche et la validation attendue ;
• l’inventaire des sources retenues et de leurs responsables ;
• un corpus initial nettoyé avec une provenance identifiable ;
• des cas de test séparés, dont quelques situations où le système doit s’abstenir ;
• une règle de maintenance et de gestion des accès.

Ce dossier est modeste. Il a pourtant plus de valeur qu’une démonstration spectaculaire branchée sur des archives mal comprises. Il permet de décider si l’IA apporte un gain réel, si une automatisation classique suffit ou si le problème doit d’abord être corrigé dans le processus métier.

Les données anciennes peuvent devenir un avantage. Pas parce qu’elles sont nombreuses. Parce qu’une entreprise sait lesquelles sont encore vraies, qui peut les utiliser et comment contrôler ce qu’elles permettent de produire.