Aucun dossier financier correspondant ?
Vérifiez le périmètre de la recherche

Supposons qu'une personne de l'équipe financière recherche des enregistrements pour une période donnée et n'obtienne aucune correspondance. Avant d'interpréter la réponse, il faut identifier la requête réellement transmise au moteur. Nous proposons de consigner l'identité de l'index, la forme de la requête, les champs interrogés, les critères de sélection, l'heure et le contexte d'accès autorisé. Gardez le résultat observé distinct de l'explication de l'assistant. La page Text Query Filters de Microsoft porte sur la recherche par mots-clés. Elle décrit les filtres comme des critères fondés sur des valeurs qui déterminent quels documents indexés sont retenus. Avec des termes de recherche, ces critères réduisent le périmètre ; sans termes, un filtre peut constituer à lui seul la sélection. Un résultat vide ne révèle pas quel critère a empêché une correspondance.

L'égalité littérale de texte diffère aussi de la recherche en texte intégral, qui analyse les mots. Microsoft précise que les filtres d'égalité textuelle ne découpent pas le texte en mots et sont sensibles à la casse par défaut ; un normaliseur configuré peut modifier ce comportement. Une sélection sur des valeurs numériques nécessite des filtres : les champs numériques ne font pas individuellement l'objet d'une recherche en texte intégral. La forme de la requête est donc un élément de preuve, pas un détail technique à écarter. Ces distinctions n'établissent pas un comportement identique pour la recherche vectorielle ou sémantique. Ne consignez les conditions liées aux permissions qu'à partir d'éléments autorisés. Un filtre de chaînes ne prouve pas, à lui seul, la sécurité du contrôle d'accès ; des résultats manquants ne justifient pas d'élargir les droits.

Microsoft décrit l'indexeur comme un mécanisme d'ingestion qui lit une source configurée pour alimenter un index destinataire. Plusieurs indexeurs peuvent contribuer au même index, y compris à des champs différents. Demandez quelles sources et quels indexeurs sont concernés, plutôt que supposer qu'un seul traitement réussi rend compte de toute la collection. Le parcours comprend l'extraction du contenu, les correspondances entre champs source et champs d'index, puis un éventuel enrichissement. Le contenu transformé nécessite des correspondances de champs de sortie pour atteindre les champs de l'index. La présence d'un enregistrement en amont ne prouve donc pas, à elle seule, que son contenu pertinent a atteint le champ interrogé. Les preuves d'actualisation dépendent également de la source. Selon la présentation générale, la détection des changements est automatique pour les blobs, mais doit être activée pour des sources comme Azure SQL et Azure Cosmos DB. Une exécution à la demande ou un calendrier indique comment le traitement peut commencer, sans prouver qu'une actualisation est terminée. Ce propos concerne les indexeurs configurés, pas toutes les implémentations qui envoient directement des données vers un index.

La page de supervision apporte une réserve décisive : une exécution peut réussir malgré des erreurs sur des documents individuels si leur nombre reste inférieur au seuil configuré dans Max failed items. Le statut de réussite ne remplace donc pas l'examen des documents en échec, des erreurs et des avertissements de l'exécution concernée. Les avertissements demandent une interprétation ; Microsoft indique qu'ils ne signalent pas toujours un problème. Il existe aussi deux niveaux de statut. Au niveau de l'indexeur, running signifie qu'il est configuré et disponible, pas nécessairement qu'il s'exécute. Chaque exécution possède son propre statut. Demandez ses heures de début et de fin, les nombres d'éléments traités et en échec, ainsi que les exceptions détaillées, en les reliant à l'index interrogé et aux sources pertinentes. Les limites temporelles comptent. Les vues du portail sont actualisées périodiquement et l'historique ne contient que les exécutions les plus récentes, jusqu'à cinquante. Demandez quels éléments couvrent la période pertinente pour la requête. Un indicateur de réussite plus récent ou un total agrégé de documents ne permet pas d'identifier si tous les enregistrements pertinents ont été inclus.

Nous proposons une fiche de couverture reliant trois éléments : la requête et le résultat observés ; le parcours configuré entre sources, champs et transformations ; et les preuves d'exécution pertinentes, avec les exceptions non résolues. Si un lien manque, indiquez la lacune et son responsable au lieu de la combler par une hypothèse. Les responsables techniques expliquent la recherche et l'ingestion ; la personne chargée de la revue financière décide ce que l'observation permet de soutenir pour la tâche. Lors d'une évaluation autorisée, demandez comment cette fiche représente un résultat vide, une exécution réussie avec des erreurs par document et des preuves manquantes sur une actualisation. Il s'agit de cas de revue proposés, non de tests réalisés ici ni de procédures imposées par le fournisseur. Aucun enregistrement n'est présumé exister ou avoir échoué à l'ingestion. Une transmission défendable peut indiquer qu'une recherche précise n'a renvoyé aucune correspondance et que sa couverture reste à établir. Elle ne doit pas remplacer discrètement ce constat par l'affirmation que les enregistrements n'existent pas. Pour un acheteur, la question utile est de savoir si la personne chargée de la revue peut retracer le périmètre et les limites de la recherche sans les deviner.