1. Transformer les attentes du modèle en contrat de données
Commencez par l’objet que votre programme attend, avant de choisir un validateur. Pour une entrée tabulaire, nommez les colonnes, les types et les unités. Pour une image, précisez dimensions, canaux et traitement des orientations. Pour un texte, définissez l’encodage, les champs obligatoires et la politique sur les entrées vides. Une donnée peut être lisible sans convenir au calcul.
Séparez trois décisions : refuser, accepter telle quelle ou transformer selon une règle documentée. Convertir une chaîne en nombre, remplacer une valeur absente et tronquer une entrée changent le contenu traité. Ces opérations ne doivent pas se produire simplement parce qu’un outil choisit un type par défaut.
L’exemple de ce guide est pédagogique et non exécuté. Il porte sur des objets contenant un identifiant et trois valeurs numériques comprises entre −100 et 100. Ces bornes sont inventées pour illustrer un contrat, sans unité physique ni lien avec un jeu de données Kernodeck. Elles doivent être remplacées par les règles du projet réel.
Faites défiler le tableau pour lire toutes les colonnes.| Niveau | Règle | Échec repérable |
|---|---|---|
| Schéma | Exactement id et values | Champ manquant ou inattendu. |
| Type | id chaîne ; values liste de nombres | Nombre présenté sous forme de texte, booléen ou valeur absente. |
| Forme | Trois valeurs par objet | Vecteur trop court ou trop long. |
| Valeur | Nombres finis dans [−100, 100] | NaN, infini ou valeur hors du domaine pédagogique. |
| Corpus | Identifiants uniques | Deux objets portent le même identifiant. |
2. Vérifier la lecture avant les conversions
Fixez le format et son dialecte. Pour un CSV, documentez séparateur, encodage et présence de l’en-tête. Le lecteur CSV standard Python renvoie normalement des chaînes ; il ne décide pas que votre colonne est un entier. Un identifiant comme 0012 peut perdre son sens si une conversion le transforme en 12. Conservez donc les identifiants dans leur type prévu.
Contrôlez le nombre de champs et les noms de colonnes avant de créer les objets métier. Une ligne décalée par un séparateur inattendu ne doit pas passer sous prétexte que certaines valeurs restent convertibles. Pour les fichiers binaires ou les images, faites également la lecture réelle : une extension correcte ne garantit pas un contenu décodable.
Un JSON décodé n’est pas encore un contrat validé. Le module Python accepte par défaut certaines valeurs non finies et des noms répétés dans un objet. Si votre format les interdit, configurez ce rejet au décodage, puis appliquez vos règles de schéma. Définissez aussi une limite de taille adaptée avant de charger un fichier complet en mémoire.
3. Isoler une erreur par type de règle
Construisez un petit ensemble où chaque entrée invalide ne viole qu’une règle importante. Vous saurez ainsi ce que le contrôle détecte. Si le seul exemple incorrect cumule un mauvais identifiant, une dimension erronée et un nombre infini, son rejet ne démontre pas que les trois règles fonctionnent.
Dans le tableau, les notations représentent des objets pédagogiques déjà lus. L’infini est une valeur numérique non finie, pas une syntaxe JSON à adopter. Les verdicts sont attendus par raisonnement et ne sont pas des sorties d’un programme exécuté. Un second objet portant a se teste après l’objet a valide pour vérifier l’unicité.
Conservez ces cas avec votre contrat lorsque celui-ci évolue. Si vous décidez d’accepter des chaînes numériques, créez une étape de conversion explicite et gardez une trace de cette décision. Ne modifiez pas silencieusement les contrôles pour faire disparaître le premier rejet du corpus.
Faites défiler le tableau pour lire toutes les colonnes.| Identifiant et valeurs | Verdict attendu | Règle exercée |
|---|---|---|
| a · [1, 2, 3] | Accepté | Référence valide. |
| b · ["4", 5, 6] | Refusé : type | Une chaîne n’est pas un nombre dans ce contrat. |
| c · [7, 8] | Refusé : forme | Deux valeurs au lieu de trois. |
| d · [0, infini, 1] | Refusé : valeur | Une valeur non finie ne peut pas entrer dans le calcul. |
| a · [4, 5, 6], après le premier a | Refusé : doublon | Unicité sur le corpus. |
4. Garder un validateur explicite et des messages exploitables
L’extrait suivant montre les contrôles sur un objet, après décodage. Il s’arrête à la première règle en échec et ne traite ni le fichier complet ni tous ses formats possibles. Le conteneur seen appartient au parcours du corpus : le recréer à chaque ligne rendrait le contrôle des doublons inutile.
Un message utile contient la règle, le fichier logique et la position de l’objet. Évitez d’y recopier tout son contenu. Pour une collecte de plusieurs erreurs, limitez les détails conservés tout en maintenant des compteurs complets. Un rapport de plusieurs gigaoctets n’aide pas davantage à localiser la première cause.
Sur un tableau NumPy, un contrôle de finitude élément par élément peut compléter les contrôles de type et de forme. Il ne remplace pas les bornes métier : un nombre fini peut encore être une longueur négative ou une valeur exprimée dans la mauvaise unité.
import math
def valider_objet(item, seen):
if type(item) is not dict or set(item) != {"id", "values"}:
raise ValueError("SCHEMA")
identifiant = item["id"]
if type(identifiant) is not str or not identifiant.strip():
raise ValueError("IDENTIFIANT")
if identifiant in seen:
raise ValueError("DOUBLON")
values = item["values"]
if type(values) is not list or len(values) != 3:
raise ValueError("FORME")
for value in values:
if type(value) not in (int, float):
raise ValueError("TYPE")
if not (-100 <= value <= 100) or not math.isfinite(value):
raise ValueError("VALEUR")
seen.add(identifiant)
return item5. Passer de l’échantillon au corpus complet
Un échantillon court permet de corriger vite le lecteur et le contrat. Choisissez des cas ordinaires et des frontières : entrée vide, taille maximale, caractère inhabituel, première et dernière partition. Une sélection des premières lignes seule peut manquer une anomalie située dans un fichier plus tardif ou dans une catégorie rare.
La validation complète parcourt toutes les entrées concernées et applique les règles globales. Pour de gros volumes, traitez les fichiers progressivement et consignez leur identité. Un ensemble de tous les identifiants en mémoire convient au petit exemple, mais peut devenir trop coûteux ; choisissez alors une stratégie d’unicité adaptée au volume, sans renoncer au contrôle.
Le rapport doit indiquer son périmètre : échantillon de mise au point, totalité d’une partition ou totalité du corpus défini. Conservez le nombre lu, accepté et refusé, ainsi que les règles appliquées. Si des fichiers changent ensuite, le rapport ancien ne valide pas automatiquement la nouvelle entrée.
6. Décider quoi faire des données refusées
Arrêtez le travail lorsque les erreurs invalident le sens du calcul : colonne essentielle absente, unités incompatibles ou correspondance des identifiants perdue. Si votre tâche autorise l’exclusion d’éléments isolés, définissez cette politique avant le lancement, conservez les refus et calculez les résultats sur le périmètre réellement accepté.
Une mise à l’écart n’est pas une correction. Si vous remplacez les valeurs manquantes ou normalisez les entrées, produisez une nouvelle version identifiable et revalidez-la. Gardez la transformation et ses paramètres avec l’expérience. Sinon, deux essais portant le même nom peuvent utiliser des données différentes.
Avant le GPU, contrôlez encore le batch réellement construit : ordre des dimensions, type numérique, masque éventuel et correspondance avec les cibles. La validation du fichier précède les transformations ; elle ne prouve pas que le pipeline conserve ensuite ces propriétés. Un cas représentatif permet de vérifier cette dernière frontière.
7. Produire une autorisation de lancement compréhensible
La sortie attendue est un rapport court qui répond à quatre questions : quelle entrée, quelles règles, quel périmètre et quelle décision. Un statut valide doit renvoyer à une identité de corpus précise. Un statut partiel doit nommer ce qui reste à contrôler. Un rejet doit permettre de retrouver les objets concernés sans diffuser leur contenu inutilement.
Ajoutez un contrôle du validateur lui-même : un cas correct passe, chaque cas incorrect est refusé pour la bonne raison, et les compteurs se réconcilient. Puis vérifiez un petit passage dans l’application. Ce double contrôle évite de confondre la conformité des données avec la qualité du modèle ou la disponibilité du GPU.
Des entrées conformes peuvent rester biaisées, mal étiquetées ou inadaptées à la question étudiée. Ce guide couvre la conformité structurelle et des règles explicites ; il ne certifie ni la représentativité ni les droits d’utilisation. Ces décisions complètent le dossier avant un traitement long.