Données prêtes pour l’IA : auditer fraîcheur, droits et provenance

L’équipe possède un export de dossiers et plusieurs centaines de procédures. Elle pense pouvoir lancer son POC IA, puis découvre une règle remplacée, des pièces sans origine et des données d’un autre établissement. Le modèle répond pourtant à la démonstration. Le problème est en amont : la disponibilité d’un fichier a été prise pour une preuve que ses données étaient utilisables.

La méthode relie chaque source à un usage, une autorité et des conditions de validité. L’audit distingue contenu exploitable, permission, fraîcheur, provenance et possibilité de retrait. Il produit un verdict par source et par famille de demandes, avec des réserves attribuées. Un bon score moyen de qualité ne doit pas compenser une source interdite ou sans propriétaire.

Nous préparons le dossier fictif d’un assistant qui propose une orientation de demandes de service internes. Il consulte dossiers, procédures et données d’organisation, sans envoyer de message ni modifier une décision. Une matrice de six sources et huit écarts illustre l’audit. Ces observations sont construites pour expliquer le raisonnement ; aucun contrôle client ni essai de modèle n’est revendiqué.

Avant de financer une IA sur mesure reliée aux processus et aux données métier, demandez quelles sources permettent de tester la mission avec les droits des futurs utilisateurs. L’audit IA avec feuille de route et POC doit notamment attribuer la correction de la procédure, la mise à jour de l’annuaire et la qualification des pièces jointes. La matrice ci-dessous montre comment ces réserves réduisent les demandes qu’un premier essai peut couvrir.

Pour qui vérifier les sources avant un POC IA

Auditer une mission plutôt qu’une base entière

Le sujet concerne métier, data, SI, sécurité et responsables de sources lorsque le projet doit quitter une démonstration sur fichiers choisis. La mission précise les demandes à traiter, les utilisateurs et la sortie utile. Une source peut convenir à une synthèse historique et rester impropre à une décision qui exige l’état courant d’un dossier.

Dans l’exemple, la sortie est une proposition d’orientation avec faits accessibles et motif à vérifier. L’audit ne cherche pas à rendre toute l’entreprise « prête pour l’IA ». Il vérifie les sources nécessaires à cette famille de demandes. Les autres usages restent hors verdict ; ils devront définir leur propre qualité utile, leurs accès et leur conséquence d’erreur.

Séparer preuve de faisabilité et preuve de valeur

La préparation des données indique ce que le POC peut tester de manière licite et techniquement crédible. Elle ne démontre pas que l’assistant fera gagner du temps, sera adopté ou réduira les erreurs. Ces résultats demandent une comparaison métier. Inversement, un besoin rentable ne rend pas une source disponible, autorisée ou assez fraîche.

Le NIST AI RMF Core relie contexte, risques, mesure et gestion tout au long du système. Pour notre audit, cela conduit à conserver la mission et ses limites avec les preuves. La matrice proposée ne constitue ni une certification NIST ni une validation globale du futur système.

Inventorier les sources à partir de la décision attendue

Lister les faits dont la sortie a besoin

Partir des applications produit une longue liste de systèmes ; partir de la sortie produit une liste de faits nécessaires. L’orientation demande le type de demande, l’établissement concerné, une règle applicable et un interlocuteur responsable. Pour chacun, l’équipe identifie la source d’autorité et ce qui peut être seulement une copie de consultation.

L’inventaire distingue dossier opérationnel, procédure approuvée, annuaire et export de démonstration. Il associe champs utiles et usages exclus. Les pièces jointes ne sont pas ajoutées par défaut parce qu’elles sont présentes dans le dossier. Une donnée qui ne change aucune étape de la mission doit avoir une justification avant d’entrer dans le contexte du modèle.

Attribuer autorité et responsabilité

Le propriétaire métier précise ce que signifie la source et quand elle est applicable. Le responsable technique précise comment elle est accessible et synchronisée. Le sponsor du POC décide du périmètre et des réserves acceptables. Ces rôles peuvent appartenir à des personnes différentes ; un développeur qui réussit l’extraction ne devient pas propriétaire de la validité d’une règle.

Un export sans contact responsable ne doit pas recevoir un statut prêt par défaut. L’équipe peut encore travailler sur sa structure avec des données synthétiques, mais ne peut pas attribuer aux résultats une validité opérationnelle. La réserve porte sur l’absence d’autorité retrouvable, avec une action et une personne chargée de la résoudre.

Retrouver l’origine et les transformations de chaque donnée

Conserver la chaîne qui permet de corriger

La provenance relie objet source, version, extraction et transformation. Pour une procédure, elle indique document approuvé, date d’application et méthode d’extraction. Pour un dossier, elle indique identifiant dans le système d’autorité et instant de lecture. Une empreinte aide à repérer un changement de contenu ; elle ne prouve pas que le contenu était correct ou autorisé.

La chaîne doit permettre de retrouver les dérivés lorsqu’une source est corrigée ou retirée. Une copie normalisée sans référence d’origine rend cette opération difficile. L’audit demande comment la modification sera propagée vers extrait, index, cache et jeu d’évaluation. À ce stade, il collecte les preuves et lacunes ; la construction détaillée du mécanisme relève du chantier d’intégration.

Documenter les pertes introduites par la préparation

Une conversion de PDF peut supprimer un tableau, inverser un ordre de lecture ou séparer une exception de sa règle. Un export peut remplacer une valeur manquante par une chaîne vide. Un rapprochement peut réunir deux établissements parce que leurs noms se ressemblent. Les transformations doivent être décrites et contrôlées sur un échantillon représentatif de leurs difficultés.

Exemple concret : la procédure PR-12 réserve une orientation à un établissement précis, mais l’extrait préparé a perdu cette condition. Le fichier est lisible et la source authentique ; son dérivé ne doit pourtant pas être utilisé pour toutes les demandes. Le verdict ferme cet usage jusqu’à correction et vérification de l’extraction. Les références de cet exemple sont fictives.

Mesurer la fraîcheur utile au cas d’usage

Distinguer modification, extraction et prise d’effet

Une date de fichier récente ne prouve pas qu’une règle est actuelle. L’audit conserve date de modification, date d’extraction, période d’application et instant d’observation lorsqu’ils changent l’usage. Une procédure ancienne peut rester applicable ; un export créé aujourd’hui peut contenir un état d’hier et manquer une nouvelle affectation.

Le seuil de fraîcheur est décidé selon la conséquence de la sortie et la cadence réelle de mise à jour. L’orientation vers un interlocuteur absent peut attendre une vérification humaine ; une action qui exige une disponibilité courante demandera une lecture plus proche de son exécution. L’audit ne fixe pas un nombre d’heures universel pour toutes les sources.

Décrire ce qui arrive lorsque la source ne suit plus

Le dossier précise comment détecter un retard de synchronisation et quel usage reste permis. Si le dernier export disponible n’atteint plus la fraîcheur convenue, le service peut signaler sa date, restreindre la proposition ou transférer la demande. Une connexion qui répond normalement peut servir des données en retard ; supervision de transport et validité métier sont distinctes.

Cas concret : l’annuaire est accessible, mais un changement d’équipe n’apparaît pas dans sa copie. L’assistant peut encore décrire le dossier ; il ne doit pas certifier le destinataire depuis cette copie si la mission exige l’affectation courante. La réserve concerne l’orientation et sa preuve de fraîcheur, sans interdire automatiquement tous les autres usages.

Distinguer accès technique et usage autorisé

Qualifier chaque utilisation et chaque destinataire

Un compte peut lire une source sans que le projet puisse envoyer l’intégralité de son contenu au fournisseur. L’audit distingue consultation par l’utilisateur, traitement par le service, transmission au modèle, stockage de dérivés et réutilisation pour évaluation ou entraînement. Les preuves portent sur l’offre et les réglages réellement utilisés, avec leur date et leur périmètre.

La CNIL, sur la conception d’un système IA, rappelle la sélection des données nécessaires selon l’objectif. Pour le dossier de préparation, nous recensons les catégories utiles et les usages exclus. La qualification juridique des données personnelles et des réutilisations reste attribuée aux responsables compétents ; un tableau de disponibilité ne la remplace pas.

Vérifier la portée avec des identités réalistes

Le jeu de vérification inclut établissement autorisé, établissement étranger, utilisateur privé d’un rôle et source partagée avec restrictions. Les permissions observées dans un compte administrateur ne prouvent pas celles du futur assistant. L’audit conserve l’identité de test et la portée obtenue, sans publier les secrets ou copier les données interdites dans un rapport de diagnostic.

Une réserve d’accès peut fermer une source ou une famille de demandes. Elle ne se compense pas par la validation humaine après génération : le contenu a déjà été transmis. Le risque est de croire qu’une donnée interne est utilisable pour tout usage interne. Les copies, journaux et sorties possèdent aussi des destinataires et doivent figurer dans le périmètre examiné.

Examiner un échantillon qui contient les cas difficiles

Observer les défauts qui changent la décision

L’échantillon contient formats courants, tableaux, scans, anciennes versions, champs absents, exceptions et objets voisins. Il relie chaque défaut à sa conséquence : orientation impossible, mauvaise règle, identité incertaine ou information interdite. Une moyenne de complétude ne dit pas quels champs manquants empêchent réellement la mission.

Les observations séparent erreur présente dans la source et perte créée par l’extraction. Le propriétaire de la donnée peut corriger la première ; l’équipe de préparation peut corriger la seconde. Le modèle n’est pas chargé d’inventer une valeur manquante pour rendre le dossier complet. Une abstention ou une demande de précision peut être la sortie attendue.

Garder les limites de représentativité

Un corpus sélectionné manuellement pour la démonstration ne représente pas automatiquement les demandes futures. Le dossier nomme les populations absentes, les biais de sélection et les cas rares qui portent un risque important. Les données synthétiques servent à tester un comportement contrôlé ; elles ne mesurent pas la fréquence des défauts dans l’activité réelle.

La CNIL, sur la collecte et la gestion des données pour l’IA, décrit notamment la pertinence et le suivi des données. Cette lecture soutient la revue des sources ; elle n’établit pas la représentativité de notre jeu fictif. Le POC doit conserver ses limites d’échantillonnage dans son verdict.

Matrice de préparation : six sources et leurs réserves

Relier la source à une preuve et à un verdict

La matrice devient utile lorsque chaque ligne nomme responsable, version ou observation, accès, usage et réserve. Le statut prêt reste lié à la mission. « Prêt sous condition » indique une limitation vérifiable ; il ne sert pas à masquer une permission inconnue. Les six lignes ci-dessous décrivent une situation fictive, sans prétendre être les résultats d’un audit exécuté.

Conserver la pièce qui justifie la couleur

Un statut seul devient vite une opinion. La ligne pointe vers preuve datée : extrait comparé, test d’accès, accord d’usage, contrôle de synchronisation ou revue métier. Elle conserve les inconnues et la prochaine action. Si la preuve concerne une version précédente, le changement de source déclenche une revue plutôt qu’une reconduction automatique du statut.

• Autorité : qui peut confirmer le sens et l’applicabilité de la source.
• Provenance : quel objet et quelle transformation ont produit le contenu.
• Accès : quelle identité peut consulter quoi, pour quel usage.
• Validité : quelle observation, condition et réserve limitent le verdict.

Le sponsor peut ainsi ouvrir un POC sur dossiers et procédures corrigées tout en excluant les pièces jointes. Cette décision doit rester visible dans l’évaluation. Le résultat ne peut pas être présenté comme preuve d’un assistant traitant des demandes qui dépendent des pièces exclues.

Vérifier accès, retrait et disponibilité avec des preuves

Exercer la source au niveau de la mission

Les contrôles proposés utilisent des objets fictifs identifiables et des identités de portée connue. Ils vérifient un accès autorisé, un accès étranger refusé, une modification propagée et une indisponibilité. La responsabilité de chaque essai est attribuée. Les résultats conservés décrivent la configuration testée et l’issue observée, sans transformer une réussite ponctuelle en garantie pour toutes les demandes.

Le contrat d’entrée nomme source, identité et usage ; sa sortie nomme contenu obtenu, version, couverture ou motif de refus. La journalisation permet de retrouver la preuve. Le repli décrit ce qui peut encore être fait sans cette source. Cette trace de faisabilité précède la construction de l’orchestration et l’évaluation de la qualité du modèle.

Tester aussi la fin d’un usage

Un document retiré ou un accès révoqué doit pouvoir cesser d’alimenter le périmètre concerné. L’audit demande comment retrouver dérivés, copies de test et sorties dépendantes. Il vérifie les chemins effectivement couverts et garde les inconnues. Un rollback applicatif ne supprime pas les données déjà copiées ou transmises.

Le contrôle peut révéler qu’un index est corrigeable, tandis qu’un export manuel reste introuvable. Le verdict doit porter cette limite. Pour un POC borné, l’équipe peut choisir une source et un environnement dont elle maîtrise le retrait, puis traiter la réserve avant extension. Elle ne doit pas déclarer le retrait global réussi sur la seule suppression du fichier d’origine.

Matrice de décision : huit écarts avant l’ouverture du POC

Décider par conséquence plutôt que par moyenne

Les écarts suivants sont des cas de décision proposés. Ils ne décrivent pas des contrôles réalisés chez un client. Le seuil d’ouverture doit être défini avant de sélectionner les exemples favorables. Une source interdite ferme son usage ; un défaut de format peut appeler correction puis contre-test ; une couverture limitée peut réduire la famille de demandes évaluée.

Garder le coût de préparation dans la décision

Le budget de POC inclut remise en état des sources, validation des extraits, qualification des usages et maintenance. Une source riche mais difficile à maintenir peut rendre un petit périmètre plus utile qu’un grand corpus. Le coût complet est comparé à la valeur de la mission, avec ses dépendances et responsabilités récurrentes.

Le verdict peut être prêt, prêt sur un périmètre réduit, à corriger ou à différer. Chaque réserve possède conséquence, propriétaire et preuve de fermeture. Une date cible ne remplace pas la preuve. L’équipe sait alors quelle hypothèse le POC teste et ce qu’une démonstration réussie ne permet pas encore de conclure.

Erreurs fréquentes des audits de données pour l’IA

Déclarer la préparation depuis la quantité disponible

Les erreurs classiques sont le nombre de documents présenté comme qualité, une date de copie présentée comme fraîcheur et la réussite d’extraction présentée comme fidélité. Une source sans clé de rattachement peut sembler complète tout en empêchant de distinguer deux dossiers. La quantité n’apporte pas l’autorité ou la provenance manquantes.

Nettoyer les données sans connaître la mission crée aussi des pertes. Une exception rare peut être éliminée comme anomalie alors qu’elle décide précisément du refus attendu. Les changements de préparation sont documentés et revus par le métier, avec une comparaison avant et après sur les cas qui engagent le plus la sortie.

Reporter les permissions après la démonstration

Un export global pour aller vite peut contourner les restrictions du système d’origine. La démonstration reçoit alors un contexte que le futur utilisateur ne pourra pas consulter. Ses résultats ne prouvent pas la faisabilité du parcours réel. Le projet doit réévaluer la mission avec le contexte autorisé, au lieu de conserver cette exception comme fondation implicite.

Autre erreur : attribuer un score global puis laisser ouvertes toutes les sources. Le dossier doit conserver les défauts bloquants et les usages fermés séparément. Une moyenne ne règle pas une permission inconnue, un contrat non qualifié ou un retrait impossible. Ces réserves demandent une décision propre et une preuve explicite.

Plan d’action : attribuer les réserves et borner la preuve

Construire le dossier d’entrée du POC

Décrivez la mission, les utilisateurs, la sortie et les faits nécessaires. Recensez seulement les sources qui portent ces faits, puis identifiez autorité, version, observations et transformations. Attribuez les responsabilités métier et techniques. Séparez les données synthétiques du contexte opérationnel afin de ne pas confondre test d’un mécanisme et représentativité de l’activité.

Remplissez la matrice avec accès, usages et réserves. Sélectionnez un échantillon comprenant exceptions, anciennes versions et identités étrangères. Demandez les preuves d’extraction, d’autorisation et de disponibilité au niveau utile. Les inconnues restent visibles ; elles deviennent des actions à attribuer et peuvent réduire le périmètre avant toute transmission au modèle.

Pour PR-12, le propriétaire de procédure confirme la condition d’établissement et l’équipe de préparation corrige l’extrait. La fermeture de réserve conserve leur comparaison et la version corrigée. Le sponsor sait alors quelle famille peut entrer dans le POC ; une simple livraison de fichier ne ferme pas la réserve métier.

Décider ce que le POC peut réellement démontrer

Rapprochez résultats des contrôles, règles de fraîcheur, usage fournisseur et capacité de retrait. Le contrat d’entrée du POC conserve la version de chaque source et ses limites. Le contrat de sortie nomme les familles de demandes évaluables, les refus attendus et la trace à conserver. Le repli rend possible une comparaison sans assistant sur les mêmes dossiers.

Décidez ouverture, correction ou report avec le sponsor et les propriétaires. La journalisation de cette décision permet de revoir le verdict après une nouvelle source ou une modification d’usage. L’évaluation mesure ensuite valeur, qualité, latence et charge de revue sur le périmètre autorisé. Une extension réexamine les réserves ; elle ne transforme pas les sources exclues en sources prêtes par héritage.

Guides complémentaires pour l’évaluation et le corpus

Relier préparation et décision d’investissement

Le protocole d’évaluation d’un POC IA métier organise référence, cas difficiles et verdict. La matrice de préparation devient une pièce d’entrée de ce protocole : elle dit quelles sources et populations peuvent être utilisées et quelles réserves limitent la conclusion.

Une source prête ne constitue pas une valeur démontrée. La comparaison doit encore conserver erreurs, abstentions et coût de vérification. Si la préparation exige une maintenance disproportionnée, le verdict peut favoriser une règle classique ou un usage réduit. Cette conséquence appartient à la décision d’investissement.

Passer du verdict source à une architecture documentaire

Le RAG documentaire avec corpus, accès et preuve de réponse approfondit la mise en œuvre d’un corpus une fois ses conditions qualifiées. Il relie extraction, recherche, citations et retrait. L’audit reste propriétaire du verdict de préparation avant POC ; il ne remplace pas ces contrôles d’architecture.

Les questions juridiques de finalité, fournisseur et conservation relèvent aussi du cadrage exposé dans IA et RGPD dans un produit web avant branchement. L’audit transmet ses faits et inconnues aux responsables de qualification, sans conclure à une conformité depuis la seule disponibilité des données.

Conclusion : déclarer une source prête pour un usage précis

La préparation des données pour l’IA porte sur une mission, une source et un usage. Propriétaire, version, provenance, droits et fraîcheur doivent pouvoir être rapprochés. La quantité ou la lisibilité d’un export ne remplace pas ces preuves.

La matrice conserve réserves, conséquences et prochaine action. Elle permet d’ouvrir un POC limité sans présenter ses exclusions comme des capacités acquises. Le verdict de préparation reste distinct de l’évaluation du modèle, de la preuve de valeur et de la qualification juridique.

L’audit IA avec préparation des sources et POC relie ces décisions à une feuille de route réaliste. Une nouvelle source ou une nouvelle finalité réexamine les conditions qui justifiaient le premier périmètre.

Pour cadrer cette IA sur mesure fondée sur des données et des usages vérifiables, Dawap examine avec vos responsables les extraits, les accès et les mises à jour nécessaires à la sortie attendue. Vous obtenez un périmètre testable et une liste de réserves attribuées, avec la preuve qui permettra de fermer chacune. Le POC peut ainsi démarrer sur les sources qualifiées sans faire disparaître du plan les pièces exclues ou les affectations trop anciennes.