Une évaluation de fraîcheur détermine, à un instant donné, si une représentation dérivée d’un avis apporte des preuves suffisantes pour un usage précis. Elle ne statue pas sur la situation juridique de la procédure. Le relevé identifie l’enregistrement, la procédure, l’avis, sa version et les lots concernés ; sépare publication officielle, modification déclarée, observation, ingestion, normalisation et dernière vérification ; recherche les avis liés et les écarts matériels ; puis renvoie fresh_for_discovery, fresh_for_triage, revalidation_required, superseding_event_found, identity_unresolved ou source_unavailable. Il précise les usages permis, les usages interdits, sa date de validité et la vérification suivante. La copie observée reste intacte.
La mention « mis à jour aujourd’hui » décrit souvent un import, pas une action de l’acheteur. Une fiche aspirée le matin peut encore reproduire l’avis initial alors qu’un rectificatif publié la veille modifie la date limite ou le dossier de consultation. À l’inverse, un avis d’attribution ancien peut rester une source historique exacte. L’âge ne suffit donc pas. Le risque apparaît lorsqu’un agent utilise une fiche de découverte pour engager une équipe, établir un calendrier, télécharger les pièces réputées applicables ou préparer un dépôt. Corriger silencieusement la fiche ne résout rien : on perd la trace de l’écart et la possibilité d’expliquer la décision.
Commencez par l’usage attendu, puis remontez de la copie vers la publication officielle avec des identifiants stables. La fraîcheur est une propriété de la preuve pour cet usage, pas un badge général posé sur l’opportunité. Un rectificatif officiel relié au même dossier l’emporte sur un horodatage récent de l’agrégateur. Un ETag, Last-Modified ou une empreinte de contenu ne porte que sur la représentation contrôlée. L’agent peut consulter des sources publiques, suivre les liens officiels, comparer les versions et demander une revalidation. Il ne peut ni modifier le dossier opérationnel, ni prononcer un no-bid, ni contacter l’acheteur, ni accepter des conditions de portail, ni agir sur un dépôt sans autorisation distincte.
Réponse directe
Une annonce est obsolète lorsque ses preuves ne suffisent plus à la prochaine décision
Il n’existe pas de durée universelle après laquelle une fiche devient fausse. Un avis ancien peut encore identifier correctement un acheteur et une procédure achevée. Une alerte créée il y a une heure peut déjà manquer un rectificatif. La première question est donc : qu’allons-nous faire de cette information ?
fresh_for_discovery autorise la conservation d’une piste lorsque l’identité et l’accès officiel sont crédibles. fresh_for_triage exige un contrôle défini des champs nécessaires au premier examen. revalidation_required signifie que la preuve ne supporte pas l’usage annoncé. superseding_event_found exige une publication officielle plus récente, reliée au même objet par des identifiants ou références contrôlables.
Ce vocabulaire ne décide pas si le marché est encore ouvert, rectifié, annulé ou remplacé. Il organise la suite. Une différence de date part vers la vérification des échéances et du fuseau ; un signal de pièces modifiées vers le registre des modifications ; une publication d’annulation ou de succession vers l’analyse de disposition.
| État | Preuve minimale | Usage permis | Suite |
|---|---|---|---|
| fresh_for_discovery | Identité plausible et localisation officielle | Créer une piste signalée comme non vérifiée | Ouvrir la source officielle avant qualification |
| fresh_for_triage | Identité et champs essentiels comparés au dernier état officiel | Effectuer un premier tri de l’opportunité | Recontrôler avant une action engageante |
| revalidation_required | Preuve insuffisante pour l’usage annoncé | Conserver uniquement comme piste | Acquérir la preuve officielle manquante |
| superseding_event_found | Événement officiel ultérieur relié au même périmètre | Ne plus exploiter le champ antérieur | Qualifier l’effet dans le contrôle spécialisé |
| identity_unresolved | Lien entre la copie et la source non démontré | Aucune fusion ni affirmation d’état courant | Lancer la résolution d’identité |
| source_unavailable | Source officielle nécessaire inaccessible | Aucune dépendance matérielle | Attribuer le rétablissement et la nouvelle tentative |
Modèle temporel
Une collecte récente peut contenir un événement ancien
La date de publication appartient à l’acte officiel. La date d’observation appartient à une représentation précise. L’ingestion et la normalisation appartiennent à votre chaîne de traitement. last_verified_at n’est légitime que si la comparaison officielle annoncée a réellement réussi. Les réunir sous « dernière mise à jour » rend le résultat impossible à auditer.
Dans eForms, l’identifiant et la version de l’avis, l’identifiant de procédure, la date d’envoi et la publication au Supplément au Journal officiel figurent dans les métadonnées. La date limite de réception des offres est un terme séparé au niveau du lot. Un passage de robot aujourd’hui ne modifie aucune de ces dates.
valid_until fixe enfin une limite d’usage interne. Elle dépend du risque, de la volatilité de la source et de la proximité de l’action. Elle ne doit jamais être affichée comme une échéance fixée par l’acheteur.
| Champ | Ce qu’il indique | Confusion à éviter |
|---|---|---|
| source_published_at | Publication de l’événement officiel | Heure de collecte |
| source_modified_at | Modification déclarée par la source | Garantie de complétude |
| observed_at | Observation d’une représentation | Actualité de toute la procédure |
| ingested_at | Entrée de la copie dans le système | Mise à jour par l’acheteur |
| normalized_at | Exécution d’une transformation | Comparaison officielle |
| last_verified_at | Dernier contrôle défini ayant réussi | Simple réponse HTTP positive |
| valid_until | Limite interne pour l’usage désigné | Date limite du marché |
Chaîne officielle
Un avis plus récent doit être relié au même dossier
Le jeu de données BOAMP diffuse les annonces publiées au Bulletin officiel et les met à disposition par API. Sa fiche de service annonce deux mises à jour quotidiennes, sept jours sur sept. Cette fréquence améliore la veille, mais ne dispense pas d’identifier le dossier et les relations entre annonces.
Les réponses exposent notamment idweb, contractfolderid, dateparution, datelimitereponse, annonce_lie, annonces_anterieures et url_avis. Ces champs permettent de chercher un rectificatif ou une publication antérieure liée. Ils sont plus probants qu’un intitulé semblable. Le texte et les pièces accessibles depuis l’avis restent toutefois à examiner pour comprendre l’effet de la publication.
Pour les avis européens, une Change Notice eForms possède sa propre identité et BT-758 référence l’avis et la version modifiés. Dans OCDS, les releases sont des événements immuables ; le record les indexe et compiledRelease rassemble les valeurs les plus récentes au moment de sa publication. Les modèles diffèrent, mais l’exigence demeure : conserver l’événement et sa relation au lieu de remplacer directement une valeur.
Une relation prouvée déclenche la comparaison des champs matériels : lot, date limite, pièces, valeur, stade et mode de remise. Si la relation reste ambiguë, renvoyez identity_unresolved. Une date plus récente ou un acheteur identique ne suffit pas.
Preuve technique
Une réponse 304 ne certifie ni les pièces ni l’état du marché
ETag et Last-Modified servent à valider une représentation sélectionnée au sens de RFC 9110. If-None-Match et If-Modified-Since peuvent éviter de retélécharger un contenu inchangé. Une réponse 304 indique que la condition enregistrée a tenu pour cette représentation.
Le périmètre est étroit. La page initiale peut rester identique pendant qu’un rectificatif paraît sous une autre URL. Une pièce jointe, une question-réponse ou un espace authentifié peut évoluer séparément. Certains sites ne fournissent aucun validateur fiable.
Une empreinte normalisée aide à comparer les champs ou fichiers choisis. Conservez la version de l’extracteur, la règle de normalisation et le périmètre du calcul. Une empreinte identique démontre seulement l’égalité de ce sous-ensemble, pas l’absence d’un nouvel événement officiel.
Pour être réutilisable par un autre agent, le relevé doit donc montrer URL, représentation, identifiants, temps, valeurs brutes et normalisées, liens entre événements et contrôles non exécutés. Le mot synced ne remplace aucun de ces éléments.
Exemple
Une alerte récente peut manquer le rectificatif déjà présent au BOAMP
Dans cet exemple fictif, une alerte enregistre le 10 novembre un avis de maintenance énergétique. Elle conserve idweb A-0001, contractfolderid C-77 et une date limite au 18 novembre à 12 h 00. Un nouvel import a lieu le 13 novembre. La fiche paraît donc récente, mais reproduit toujours les valeurs de l’avis initial.
La consultation de l’API BOAMP le 13 novembre retourne également un rectificatif fictif A-0002, paru le 12 novembre. contractfolderid reste C-77 et la relation d’annonce renvoie vers A-0001. Le rectificatif reporte la date au 25 novembre à 12 h 00 et indique qu’une version corrigée du dossier de consultation doit être utilisée.
L’évaluation conserve la date du 18 novembre et l’horodatage de l’alerte comme observation. Elle ajoute le rectificatif, sa relation et les écarts, puis renvoie superseding_event_found pour tout usage de la date ou des pièces. Elle ne change pas directement la fiche et ne conclut pas que la procédure est ouverte.
Le contrôle des échéances vérifie ensuite l’heure, le fuseau et le stade applicables. Le registre des modifications reconstitue les pièces à utiliser. La fiche initiale peut encore servir à retrouver le dossier, mais ni le planning, ni le chiffrage, ni un dépôt ne doivent reprendre ses anciennes valeurs.
| Élément | Constat | Conséquence |
|---|---|---|
| Alerte A-0001 | Importée le 13 novembre, échéance au 18 | Copie récente d’une valeur initiale |
| Rectificatif A-0002 | Paru le 12 novembre | Événement officiel ultérieur |
| contractfolderid C-77 | Même dossier dans les deux annonces | Ancrage d’identité |
| Relation d’annonce | A-0002 renvoie vers A-0001 | Succession étayée |
| Nouvelles valeurs | 25 novembre et dossier corrigé | Anciennes valeurs interdites |
| freshness_state | superseding_event_found | Lancer les contrôles spécialisés |
Contrat agent
La sortie expose la preuve, sa limite d’usage et le prochain contrôle
La sortie structurée comprend assessment_id, record_id, intended_use, assessed_at, source_role, source_url, source_record_id, procedure_id, notice_id, notice_version, lot_ids, source_published_at, source_modified_at, observed_at, ingested_at, normalized_at, last_verified_at, representation_etag, representation_last_modified, content_fingerprint, advertised_deadline_raw, candidate_events, material_differences, freshness_state, allowed_uses, prohibited_uses, valid_until, confidence, review_owner et recheck_trigger.
L’agent peut lire des sources publiques anonymes, appeler les API documentées, suivre les références officielles, faire une requête conditionnelle et produire les différences. Il s’arrête lorsque l’identité n’est pas résolue, qu’une source obligatoire demande des identifiants, qu’une limitation d’accès empêche l’inspection, que la relation entre avis est incertaine ou qu’une décision de statut est nécessaire.
Modifier le CRM, effacer une fiche, arrêter la poursuite, s’inscrire sur un portail, employer des identifiants, contacter l’acheteur ou déposer une offre relève d’autorisations séparées. L’évaluation de fraîcheur transmet un dossier de preuve ; elle n’exécute aucune de ces actions.
Ce qui caractérise un bon résultat
Résultats concrets pour annonce de marché obsolète
- Chaque conclusion désigne la copie, la procédure, le lot, l’usage visé et l’instant d’évaluation.
- Les dates de publication, de collecte, de traitement et de vérification restent distinctes.
- Un import récent ne peut plus masquer une publication source dépassée.
- Les rapprochements reposent sur les identifiants d’avis et de dossier, pas sur un titre ressemblant.
- Les rectificatifs, résultats et autres événements ultérieurs sont conservés comme éléments de preuve.
- Un conflit de date limite déclenche le contrôle spécialisé sans fabriquer un statut ouvert ou fermé.
- Les validateurs HTTP et empreintes restent des preuves techniques à portée limitée.
- Le résultat expose les usages autorisés, les interdictions, l’échéance et le propriétaire du prochain contrôle.
- La donnée observée n’est jamais écrasée par une correction sans provenance.
Modèle opératoire
Comment exécuter le travail
- 01
Figer la copie et la décision visée
Conservez la fiche, la ligne de flux ou la réponse API telle qu’elle apparaît, puis nommez l’action qu’elle doit éclairer et l’heure d’évaluation avec son décalage.
- 02
Dissocier toutes les horloges
Enregistrez séparément la publication de la source, sa modification déclarée, votre observation, l’ingestion, la transformation et la dernière comparaison officielle réussie.
- 03
Établir l’identité officielle
Rapprochez les identifiants de procédure, d’avis, de version, de dossier et de lot avant de considérer une publication plus récente comme liée.
- 04
Chercher un événement plus récent
Interrogez l’historique officiel, la plateforme opérationnelle et les avis liés pour trouver un rectificatif, un résultat, une annulation, une nouvelle pièce ou une autre date limite.
- 05
Décider de l’aptitude à l’usage
Choisissez l’état de fraîcheur le plus étroit que les preuves permettent et bloquez explicitement les utilisations non couvertes.
- 06
Conserver et programmer la suite
Gardez la copie et les événements candidats, attribuez les conflits ou indisponibilités et fixez le prochain contrôle selon le risque et la proximité de l’échéance.
Évaluation
Les questions qui changent la décision
- Quelle représentation exacte et quels champs sont évalués ?
- À quelle décision ou action cette donnée doit-elle servir ?
- Quels identifiants de procédure, d’avis, de version, de dossier et de lot sont établis ?
- Quand l’autorité a-t-elle publié ou modifié l’information source ?
- Quand la représentation a-t-elle été observée, ingérée, normalisée et vérifiée ?
- Une publication officielle ultérieure est-elle reliée au même périmètre ?
- La date limite, les pièces, la valeur, le stade ou le canal de remise diffèrent-ils ?
- Que démontrent précisément le validateur HTTP ou l’empreinte disponibles ?
- La preuve suffit-elle à la découverte, au premier tri, ou à aucun des deux ?
- Quel contrôle spécialisé doit précéder la prochaine action engageante ?
Modes d’échec
Où les équipes perdent le contrôle
La date du dernier import est présentée comme une mise à jour de l’acheteur.
Un avis historique exact est disqualifié uniquement parce qu’il est ancien.
Deux consultations distinctes sont fusionnées à cause d’intitulés proches.
Une date dépassée est traduite en procédure fermée sans recherche de rectificatif.
Un avis lié est ignoré parce que l’URL de l’avis initial répond encore.
Une erreur temporaire ou une redirection du portail est interprétée comme une annulation.
Une réponse 304 est étendue à des pièces et publications qu’elle ne couvre pas.
Un document remplacé sous le même nom échappe à la comparaison.
L’agent écrase la copie initiale et supprime la preuve du retard de diffusion.
Une donnée suffisante pour une alerte passe directement dans le chiffrage ou le dépôt.
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.
- évaluations indiquant l’usage et assessed_at
- horodatages de source, d’observation, d’ingestion et de vérification séparés
- rapprochements fondés sur les identifiants d’avis, de version, de dossier et de lot
- événements ultérieurs conservés avec URL officielle et type de relation
- écarts matériels détectés avant tout travail dépendant
- états assortis d’usages permis, d’une échéance et d’un déclencheur de contrôle
- validateurs techniques accompagnés du périmètre exact de la représentation
- observations brutes préservées sans écrasement silencieux
Questions
Questions fréquentes
Après combien de jours une annonce devient-elle obsolète ?
Il n’existe pas de seuil universel fiable. L’usage, la dernière vérification, les événements ultérieurs et la proximité de l’échéance comptent davantage que l’âge seul.
Un import effectué aujourd’hui garantit-il des données à jour ?
Non. Il date l’entrée de la copie. Il faut encore contrôler la publication source, la version de l’avis, l’historique officiel et les champs nécessaires à la prochaine décision.
Une date limite passée prouve-t-elle que le marché est fermé ?
Non. Elle impose une revalidation rapide. Un rectificatif a pu prolonger le délai, ou la date copiée peut concerner un autre lot ou un autre stade.
Un agent peut-il remplacer automatiquement une ancienne date ?
Pas silencieusement. Il conserve l’observation, joint la publication officielle ultérieure et soumet toute modification du dossier opérationnel au processus autorisé.
Que prouve une réponse 304 Not Modified ?
Elle valide la représentation sélectionnée par rapport à la condition HTTP enregistrée. Elle ne couvre ni les avis séparés, ni toutes les pièces, ni les messages privés du portail.
Quelle différence entre une fiche obsolète et un marché fermé ?
Obsolète décrit l’aptitude d’une copie à un usage. Fermé décrit la situation de la procédure après un contrôle officiel dédié. L’un ne permet pas de déduire l’autre.
Faut-il supprimer la fiche initiale après un rectificatif ?
Pas sur la seule base de ce contrôle. Conservez-la comme provenance, reliez l’événement ultérieur et laissez les règles autorisées de données et de conservation décider de son affichage.
Quand faut-il vérifier l’annonce de nouveau ?
Le déclencheur dépend du prochain usage, de la volatilité de la source et de la distance à l’échéance. Toute dépendance à une date, une pièce, un statut ou un canal de dépôt exige une vérification officielle adaptée.
Sources
Sources primaires
- Jeu de données des annonces du BOAMP Direction de l’information légale et administrative
- Service public de l’API BOAMP et fréquence de mise à jour Direction de l’information légale et administrative
- Métadonnées et identifiants d’un avis eForms Office des publications de l’Union européenne
- Structure d’un avis de changement eForms Office des publications de l’Union européenne
- OCDS, releases immuables et records Open Contracting Partnership
- Listes OCDS pour mises à jour, modifications et statuts Open Contracting Partnership
- RFC 9110 sur ETag et Last-Modified RFC Editor
À propos de l’auteur
Tony Kim
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.
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.