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.
Benchmark
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.
| Champ | Valeur à conserver | Raison |
|---|---|---|
| Départ | Système, édition, code et libellé officiel | Garde le choix constant |
| Surface | Portail, endpoint ou version d’interface | Rend le comportement reproductible |
| Période | Dates de publication et territoire | Rend les voies comparables |
| Périmètre | Types et statut des avis | Évite les dénominateurs mélangés |
| Pertinence | Règles d’inclusion et de rejet | Limite la dérive du jugement |
| Jeu test | Identifiants officiels déjà jugés | Éprouve les manques connus |
| Budget | Fiches ou minutes par cycle | Définit la largeur utilisable |
Expérience
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écision
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.
| Voie | Preuve à garder | Décision habituelle |
|---|---|---|
| Code exact | Pertinents, rejets et manques connus | Garder comme base |
| Enfants choisis | Ajouts utiles uniques et avis au parent | Garder les enfants nommés |
| Parent seul | Gain marginal et coût de revue | Rejeter ou conditionner |
| Parent plus texte | Gain retrouvé après contrainte | Garder avec filtre |
| Voisin étayé | Preuve acheteur et valeur unique | Tester ou rejeter |
| Exclusion | Bruit retiré et pertes pertinentes | Automatiser si sûre |
| Contrôle texte | Avis pertinents hors voies code | Conserver en parallèle |
Exploitation
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.
Ce qui caractérise un bon résultat
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.
Modèle opératoire
Comment exécuter le travail
- 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.
- 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.
- 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.
- 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.
- 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.
Évaluation
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?
Modes d’échec
Où les équipes perdent le contrôle
Le portail développe peut-être déjà le niveau choisi et crée des doublons cachés.
Un benchmark limité aux anciens gains ignore des besoins nouveaux mais pertinents.
Un parent paraît productif à cause du volume plutôt que de ses avis utiles.
Une recherche par enfants manque les avis classés au parent uniquement.
Un mot négatif peut retirer un contrat mixte pourtant valable.
La précision avant déduplication récompense injustement les avis répétés.
Une mise à jour de la taxonomie ou du portail invalide la règle.
Mesure
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
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
Sources primaires
- Vocabulaire commun pour les marchés publics Commission européenne
- API de recherche TED Office des publications de l’Union européenne
- Exemples TED de requêtes sur l’objet acheté Office des publications de l’Union européenne
- United Nations Standard Products and Services Code Programme des Nations Unies pour le développement
- Evaluation of unranked retrieval sets Stanford University
Zelius
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.