Maturité des données pour l'IA : la liste de contrôle du dirigeant

« Nos données ne sont pas prêtes pour l’IA » est la phrase la plus répétée en réunion préparatoire, et elle est presque toujours imprécise. Les données ne sont pas prêtes ou non prêtes dans l’absolu. Elles sont adaptées ou inadaptées à un cas d’usage déterminé, dans des conditions déterminées, pour une durée déterminée.

Un même ensemble peut parfaitement suffire à un prototype interne en lecture seule et se révéler nettement insuffisant pour un système qui réécrit dans un dossier client. La vérification commence donc non par les données, mais par le travail.

1. Finalité : nommer la décision ou la tâche

Formulez la finalité en langage opérationnel. « Utiliser les données clients avec de l’IA » ne fournit aucun critère d’appréciation. « Résumer les trois dernières interactions de service validées pour un conseiller avant un appel » désigne un utilisateur, une tâche, une limite de source et un résultat. Seule la seconde est évaluable.

La finalité a aussi une portée juridique. Le règlement (UE) 2024/1689 rattache la classification et les obligations à la destination du système, et les exigences de gouvernance des données pour les systèmes à haut risque en dépendent directement.

2. Inventaire : suivre le trajet réel des données

Suivez le trajet tel qu’il est, non tel qu’il est documenté. Où naît l’enregistrement, par combien de systèmes passe-t-il, où est-il transformé, où est-il recopié dans un tableur et où est-il ressaisi à la main. Les étapes manuelles comptent, car c’est là que la provenance se perd.

Un résultat utile de cette étape est la liste des endroits où une même valeur existe en deux versions. Si l’organisation ne sait pas laquelle fait foi, aucun modèle ne tranchera à sa place.

3. Base légale : distinguer le possible du permis

L’accès technique n’est pas une autorisation. Pour chaque source, il faut savoir sur quelle base elle a été collectée, pour quelle finalité, et si l’usage envisagé est compatible avec celle-ci. Le règlement général sur la protection des données fixe le cadre, et les recommandations de la CNIL sur l’intérêt légitime précisent l’analyse lorsque c’est cette base qui est retenue pour le développement d’un système d’IA.

Si les données proviennent de l’extérieur ou sont partagées, le règlement (UE) 2022/868 sur la gouvernance des données et le règlement (UE) 2023/2854 sur les données peuvent également s’appliquer. Le contrat avec le fournisseur du système n’écarte aucun des deux.

4. Les données des salariés forment un cas à part

Dès qu’un ensemble permet de remonter à un salarié identifié, la protection des données s’accompagne du dialogue social. L’introduction d’un système susceptible d’affecter l’organisation du travail ou de permettre le contrôle de l’activité relève de la consultation du comité social et économique, et l’information des personnes sur les dispositifs de suivi est une obligation distincte.

Cela concerne plus de projets que les équipes ne l’anticipent. Temps de traitement par gestionnaire, notation qualité de dossiers individuels, analyse d’appels de service : tout cela permet d’apprécier une activité individuelle, même si le projet vise l’amélioration d’un processus. La question relève de l’inventaire, pas de la recette.

5. Nécessité : le minimum qui fait le travail

Il est tentant de transmettre tout le disponible en comptant sur le modèle pour trier. Cela augmente le risque, le coût et la portée de toute erreur future. Partez du plus petit ensemble capable d’accomplir la tâche et n’ajoutez que lorsque l’évaluation révèle un manque précis.

La minimisation est aussi un avantage pratique en interne. Un cas d’usage qui exploite trois champs se fait approuver bien plus facilement qu’un cas qui réclame l’accès au dossier complet.

6. Qualité : l’aptitude à cet usage précis

La qualité n’est pas abstraite. C’est un ensemble de propriétés concrètes, appréciées au regard de la tâche : complétude des champs utilisés, fraîcheur au regard du rythme de changement, homogénéité du format, et existence d’une définition telle que deux personnes rempliraient le champ de la même manière.

Un champ en texte libre là où le processus prévoit un code est un motif connu. Il laisse généralement le prototype intact et fait échouer le passage à l’échelle.

7. Représentativité : savoir qui et quoi manque

Le volume ne garantit pas la couverture. Demandez si les données couvrent les personnes, les types de documents, les langues, les produits, les canaux et les conditions d’exploitation dans lesquels le système sera utilisé. Un modèle de classification peut sembler exact dans l’ensemble et échouer systématiquement sur une catégorie réduite mais lourde de conséquences.

Pour des processus francophones, la dimension linguistique compte. Une évaluation menée sur des textes anglais dit peu de la performance sur une correspondance française comportant terminologie métier, abréviations et formulations propres au secteur.

8. Traçabilité et évaluation

Si un résultat influence une décision, il faut pouvoir reconstituer d’où il vient : quel enregistrement, quelle version, à quel moment. Ce n’est pas seulement une exigence de contrôle, c’est la condition d’une correction ciblée des erreurs.

Le jeu d’évaluation est petit, difficile et vous appartient. Il contient des cas réels dont la bonne réponse est connue, y compris les cas limites. Le constituer prend du temps une fois et sert ensuite à chaque changement de modèle, de fournisseur ou de version. Les fonctions Map et Measure du NIST AI Risk Management Framework donnent une structure pour ce qui est décrit et ce qui est mesuré.

9. Responsabilité : rendre la maturité continue

La maturité n’est pas un état atteint une fois. Les sources changent, les champs sont redéfinis, les intégrations réécrites. Il faut un responsable des ensembles précis utilisés par des systèmes précis, et un rythme de revue qui capte le changement avant qu’il ne se manifeste par un résultat dégradé.

Les données historiques portent les décisions historiques

Les données de résultats passés constituent le matériau le plus accessible et le plus souvent mal compris. Elles ne décrivent pas ce qui était vrai ; elles décrivent ce qui a été décidé et consigné. Si certains dossiers ont été traités plus sévèrement pendant des années, écartés plus tôt, ou jamais enregistrés, le modèle apprendra la pratique et non la réalité.

C’est particulièrement visible sur les données d’acceptation. Il n’existe généralement aucune donnée sur le comportement des dossiers refusés, puisqu’ils n’ont jamais eu l’occasion de le manifester. Un modèle entraîné sur les seuls dossiers acceptés optimise la reproduction du seuil antérieur, non l’amélioration de la décision.

Trois questions le révèlent vite. Quels cas sont absents des données et pourquoi. Les règles ou les seuils ont-ils changé sur la période couverte. Et sait-on qui a pris la décision — une personne, une règle, ou un système antérieur. Si la réponse à la troisième manque, l’ensemble n’est pas apte à un usage qui affecte l’accès de personnes à un service.

Une décision de maturité sur une page

Le résultat n’est pas « prêt » ou « pas prêt ». C’est une phrase assortie d’un périmètre : apte à un prototype en lecture seule sur des documents validés, mais pas à l’écriture dans un dossier client ; apte pour une équipe et une langue, mais pas pour l’ensemble de l’organisation. Le périmètre est un contrôle — et le seul qui puisse être institué avant toute dépense.

Un catalogue de données n’est pas une maturité

Beaucoup d’organisations confondent l’existence d’un catalogue de données, ou d’un outil de gouvernance, avec l’aptitude à un usage IA. Ce sont des choses différentes. Un catalogue décrit ce qui existe et où cela se trouve ; la maturité répond à une question plus étroite : cet ensemble précis soutient-il ce cas d’usage précis, dans ces conditions, pour cette durée. Un catalogue exemplaire peut coexister avec des données inaptes, et un tableur bien tenu peut suffire à un premier usage borné.

Le signe distinctif est le sens de la question. Le catalogue part des données et cherche des usages ; la maturité part de l’usage et interroge les données. Une organisation qui présente son catalogue comme preuve de préparation a généralement sauté l’étape 1, la finalité, et se retrouve à évaluer des données sans critère pour dire si elles suffisent. L’outil est utile ; il ne remplace pas le jugement porté sur un usage nommé.

Un test rapide tranche la confusion : demandez, pour le cas d’usage en cause, quel enregistrement fait foi lorsque deux systèmes divergent. Le catalogue indique où vivent les deux copies ; il ne dit pas laquelle gouverne. Cette réponse relève de la maturité, et son absence est précisément le défaut que le catalogue masque le plus souvent.

Ce que cette vérification ne peut pas faire

L’examen de maturité n’améliore pas les données. Il montre où elles ne soutiennent pas l’intention, ce qui est souvent inconfortable, car la correction est lente et ne ressemble pas à de l’innovation. Il ne prédit pas non plus si le cas d’usage créera de la valeur — des données adaptées sont une condition, pas une garantie.

Si vous souhaitez une évaluation structurée de l’aptitude de vos données à un cas d’usage IA précis, commencez par le diagnostic gratuit.

Cet article est une adaptation de l’original anglais. En cas de divergence, la version anglaise fait foi.