Une politique d’expansion indique quels niveaux autour d’un code de départ approuvé seront interrogés. Elle sépare le code exact, les enfants choisis, le parent et toute branche voisine en requêtes distinctes. Pour chacune, elle conserve portail, édition du système, expression exécutée, période testée, ajouts utiles, faux positifs, exclusions, coût de revue et décision. La table parent, enfants et exclusions devient une règle de recherche reproductible, pas une accumulation de catégories susceptibles de contenir vaguement l’offre.

Le code exact peut manquer les acheteurs qui publient à un niveau plus large. Son parent peut les retrouver, mais ramener en même temps des centaines d’avis voisins. Cocher tous les enfants donne une impression de précision et oublie les avis classés uniquement au parent. Le comportement du portail change encore le résultat: certaines interfaces développent la hiérarchie, d’autres cherchent seulement la valeur saisie. Une équipe finit souvent par surveiller une division entière puis cesse de lire l’alerte. À l’inverse, une alerte étroite semble efficace par son faible volume, même lorsque des avis pertinents connus n’y figurent pas.

La forme de la taxonomie ne décide pas seule de la largeur. Exécutez séparément code exact, enfants et parent dans le portail cible, avec les mêmes dates, territoires et types d’avis. Écrivez une règle de pertinence et confrontez chaque voie à des avis connus. La précision se mesure sur les résultats jugés. N’appelez le rappel que couverture du benchmark tant que l’ensemble complet des avis pertinents reste inconnu. Une branche plus large est retenue si ses résultats utiles uniques valent le temps de revue supplémentaire. Contraignez les parents bruyants par sujet, acheteur, secteur ou exclusions. Un agent peut lancer les requêtes, dédupliquer et calculer la table, mais il doit rendre les résultats non jugés au lieu de les qualifier.

Soumettre chaque niveau au même test de recherche

Commencez une fois le code de départ approuvé pour l’offre. Le choix du code demande quelle catégorie décrit l’objet acheté; l’expansion demande quelle quantité de hiérarchie voisine mérite une surveillance. Figez un portail, une version d’interface ou d’API, une édition de la classification, une période de publication close, un territoire et des types d’avis. Formulez une règle qu’un second réviseur saurait appliquer. Par exemple, un avis est pertinent si son objet principal exige une mise en œuvre ou une exploitation que le fournisseur livre, dans un pays couvert, sans condition obligatoire qui rend immédiatement l’opportunité impossible. Le code seul ne satisfait jamais cette règle.

Constituez un petit jeu de référence avec des avis officiels déjà jugés pertinents ou non. Ajoutez les cas inconfortables: avis pertinent codé seulement au parent, avis non pertinent portant le code exact, contrat mixte et fiche trouvée par texte plutôt que par classification. Ce jeu ne représente pas toute la vérité du marché. Il sert à révéler les angles morts manifestes. Lorsque le nombre total d’avis pertinents est inconnu, publiez une couverture des éléments connus ou un rappel du benchmark, pas un rappel absolu. Le dénominateur de précision comprend les fiches réellement examinées. La portion non jugée reste visible et ne devient pas silencieusement non pertinente.

Fiche du test de recherche
ChampValeur à conserverRaison
DépartSystème, édition, code et libellé officielGarde le choix constant
SurfacePortail, endpoint ou version d’interfaceRend le comportement reproductible
PériodeDates de publication et territoireRend les voies comparables
PérimètreTypes et statut des avisÉvite les dénominateurs mélangés
PertinenceRègles d’inclusion et de rejetLimite la dérive du jugement
Jeu testIdentifiants officiels déjà jugésÉprouve les manques connus
BudgetFiches ou minutes par cycleDéfinit la largeur utilisable

Exécuter séparément code exact, enfants et parent

Dessinez seulement la branche locale autour du code: son parent, ses enfants et tout voisin soutenu par la pratique réelle des acheteurs. Une hiérarchie n’autorise pas la surveillance de tout l’arbre. Le CPV standardise le sujet des marchés publics européens. L’UNSPSC permet de monter ou descendre dans une hiérarchie à cinq niveaux pour obtenir plus ou moins de détail analytique. Ces propriétés décrivent les vocabulaires, pas le fonctionnement de chaque formulaire. La documentation TED traite aussi le CPV de manière hiérarchique; son exemple SPARQL emploie un préfixe de code et les relations SKOS broader pour les sous-types. Votre portail peut adopter un autre contrat de requête. Son comportement doit être observé et sauvegardé.

Créez une voie pour le code exact, une pour les enfants envisagés, une pour le parent et des voies séparées pour les voisins étayés. Ajoutez un contrôle texte issu du vocabulaire de l’offre. Pour un code bruyant, testez une variante combinée avec une expression qui discrimine le bon sujet. Dédupliquez par identifiant officiel avant toute comparaison. Un avis trouvé par le parent, un enfant et le texte reste une opportunité, pas trois succès. Gardez cependant la provenance de découverte: elle révèle si l’expansion a réellement apporté un résultat unique.

  • Ne jamais déduire le traitement des descendants du seul sélecteur visuel.
  • Enregistrer requête littérale, heure et nombre de résultats pour chaque voie.
  • Distinguer classification principale et secondaire lorsque la source le permet.
  • Dédupliquer sur un identifiant officiel stable avant le calcul.
  • Conserver un contrôle texte pour révéler les avis classés autrement.

Décider sur le gain marginal, pas sur le volume brut

La précision est la part des fiches pertinentes parmi les fiches retournées et jugées. Le rappel est la part de tous les éléments pertinents qui ont été retrouvés. Dans un corpus ouvert d’avis, le second ensemble reste généralement inconnu. Utilisez donc un jeu de référence daté et déclarez cette limite. La mesure décisive est marginale: combien d’avis pertinents cette voie apporte-t-elle que les voies déjà approuvées n’ont pas trouvés? Placez en regard ses faux positifs uniques et les minutes de revue. Un parent qui ajoute six avis utiles et 240 avis étrangers peut être moins praticable qu’un enfant qui en ajoute quatre avec douze rejets. La valeur d’un avis manqué et la capacité réelle de l’équipe déterminent le choix.

Avant de rejeter le parent, testez une ou deux contraintes compréhensibles. Une expression de sujet isole le service visé; un acheteur ou un secteur contient une branche voisine; une exclusion retire un contaminant récurrent. Vérifiez toute exclusion sur les contrats mixtes. Retirer le matériel peut aussi cacher une intégration de systèmes pertinente comprenant des équipements. Réduisez alors la règle négative ou laissez ce cas à la revue humaine. Arrêtez le réglage lorsqu’un filtre supplémentaire supprime des ajouts pertinents, dépasse le budget ou dépend d’une distinction que la source ne fournit pas de façon fiable.

Table de décision parent, enfants et exclusions
VoiePreuve à garderDécision habituelle
Code exactPertinents, rejets et manques connusGarder comme base
Enfants choisisAjouts utiles uniques et avis au parentGarder les enfants nommés
Parent seulGain marginal et coût de revueRejeter ou conditionner
Parent plus texteGain retrouvé après contrainteGarder avec filtre
Voisin étayéPreuve acheteur et valeur uniqueTester ou rejeter
ExclusionBruit retiré et pertes pertinentesAutomatiser si sûre
Contrôle texteAvis pertinents hors voies codeConserver en parallèle

Publier une politique exécutable et contestable par un agent

Transformez la table en instructions versionnées. Chaque voie approuvée indique système et édition, chemin hiérarchique, requête exacte, termes associés, exclusions, portail, territoire, types d’avis, fenêtre testée, volumes, part jugée, ajouts marginaux, propriétaire et prochain déclencheur. Les voies rejetées restent dans la fiche. Sans leur motif, un analyste ou un agent réactivera le parent large et répétera le même bruit. Séparez les faits observés dans le portail des choix de politique faits par l’équipe.

Un agent peut exécuter les recherches approuvées en lecture seule, normaliser et dédupliquer les identifiants, joindre les liens sources, calculer les mesures et signaler une dérive. Il doit s’abstenir si la syntaxe change, si le code disparaît, si une exclusion entre en conflit avec un nouvel avis pertinent ou si trop de résultats demeurent non jugés. L’action sûre est alors de rendre la voie concernée avec ses preuves. Élargir la découverte n’autorise ni qualification, ni contact, ni inscription, ni dépôt. La politique fonctionne lorsqu’une personne comprend chaque branche et qu’une nouvelle preuve peut la modifier sans reconstruire l’expérience.

  • Versionner ensemble édition du code et requête exécutable.
  • Séparer les observations des décisions d’approbation.
  • Fixer des seuils de dérive pour volume, précision, manques et comportement.
  • Exiger une revue après changement d’exclusion ou de sémantique hiérarchique.
  • Garder la découverte distincte de la qualification bid.

Résultats concrets pour élargir recherche code marchés publics

  • Chaque étude part d’un code approuvé et d’un portail cible.
  • Code exact, parent, enfants et voisins sont évalués comme voies distinctes.
  • Période, territoire, types d’avis et règle de pertinence restent fixes.
  • Les ajouts pertinents uniques sont séparés du volume dupliqué.
  • Précision, couverture du benchmark et effort de revue restent distincts.
  • Les codes larges portent des filtres associés et des exclusions justifiées.
  • Une personne ou un agent peut reproduire et contester chaque choix.

Comment exécuter le travail

  1. 01

    Figer les conditions

    Nommez portail, édition, code de départ, période, territoire, types d’avis, règle de pertinence et maximum de fiches ou minutes par cycle.

  2. 02

    Séparer les voies de requête

    Exécutez code exact, enfants sélectionnés, parent et voisins étayés séparément. Conservez la requête littérale et toute expansion automatique du portail.

  3. 03

    Juger et dédupliquer

    Appliquez la même règle aux avis, gardez leurs identifiants officiels et séparez les ajouts uniques des fiches déjà trouvées ailleurs.

  4. 04

    Évaluer le gain marginal

    Comparez avis pertinents uniques, faux positifs uniques et minutes de revue par voie. Testez des contraintes avant d’approuver un parent bruyant.

  5. 05

    Publier une politique bornée

    Approuvez, conditionnez ou rejetez chaque branche avec exclusions, règles d’arrêt, propriétaire, date de revue et preuve de réouverture.

Les questions qui changent la décision

  • Le moteur cible traite-t-il le parent comme valeur exacte ou inclut-il ses descendants?
  • Quels avis pertinents connus le code de départ retrouve-t-il ou manque-t-il?
  • Les enfants ajoutent-ils des avis absents du résultat exact?
  • Le parent ajoute-t-il un travail pertinent ou surtout des sujets adjacents?
  • Quel filtre texte, acheteur, territoire ou type d’avis rend la branche exploitable?
  • Combien de temps humain l’alerte récurrente peut-elle consommer?
  • Quelle exclusion reste sûre face à un contrat mixte?
  • Quelle nouvelle preuve déclenchera le prochain examen?

Où les équipes perdent le contrôle

01

Le portail développe peut-être déjà le niveau choisi et crée des doublons cachés.

02

Un benchmark limité aux anciens gains ignore des besoins nouveaux mais pertinents.

03

Un parent paraît productif à cause du volume plutôt que de ses avis utiles.

04

Une recherche par enfants manque les avis classés au parent uniquement.

05

Un mot négatif peut retirer un contrat mixte pourtant valable.

06

La précision avant déduplication récompense injustement les avis répétés.

07

Une mise à jour de la taxonomie ou du portail invalide la règle.

Mesurer le travail terminé

La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.

  • résultats jugés et pertinents par voie de requête
  • précision après déduplication des avis
  • avis pertinents connus retrouvés par voie
  • ajouts pertinents uniques du parent, des enfants et des voisins
  • faux positifs uniques créés par chaque expansion
  • minutes estimées de revue par nouvel avis utile
  • volume hebdomadaire face au budget de revue approuvé
  • décisions revalidées après modification du système ou portail

Questions fréquentes

Une alerte doit-elle toujours inclure le code parent?

Non. Testez-le comme une voie autonome. Gardez-le lorsque ses avis pertinents uniques justifient les faux positifs et le coût, souvent avec un filtre associé.

Le parent recherche-t-il automatiquement tous les enfants?

Pas dans tous les portails ou interfaces. Vérifiez le comportement réel, sauvegardez l’expression et testez-la avec des avis connus codés sur un enfant.

Peut-on mesurer le vrai rappel d’une veille ouverte?

Généralement non, car l’ensemble complet des avis pertinents est inconnu. Publiez la couverture d’un jeu de référence daté et rendez cette limite explicite.

Un agent peut-il régler automatiquement l’expansion?

Il peut exécuter des tests bornés et proposer un changement. Un réviseur approuve les branches et exclusions, car pertinence, valeur manquée et capacité sont des choix métier.

Sources primaires

Tony Kim

Tony Kim

Fondateur et CEO

Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.

Veille sur les appels d’offres et exécution pilotée pour les équipes qui visent un résultat commercial.

Prestataires, fondateurs et équipes commerciales qui répondent aux marchés publics ou privés. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.