---
title: "Ces deux avis désignent-ils le même appel d’offres?"
description: "Distinguez les reprises d’un même avis, ses versions, les événements liés et les lots avant de masquer un résultat comme doublon."
canonical: "https://zephior.com/fr/insights/detect-duplicate-tender-notices"
last-updated: 2026-09-03
---

# Ces deux avis désignent-ils le même appel d’offres?

> Distinguez les reprises d’un même avis, ses versions, les événements liés et les lots avant de masquer un résultat comme doublon.

Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Publié le 2026-09-03; mis à jour le 2026-09-03. 17 min de lecture.

## Définition

Une décision de rapprochement décrit le lien entre deux observations datées à cinq niveaux: représentation web, avis et version, procédure d’achat, lot et action attendue du candidat. « same_publication_representation » signifie que les deux sources reproduisent la même publication et la même version. « same_notice_different_version » conserve plusieurs versions éditoriales d’un avis. « same_procedure_related_event » rattache mise en concurrence, rectification, résultat, modification ou achèvement à une procédure sans les confondre. Un avis eForms de planification n’a pas d’identifiant de procédure; l’avis ultérieur le cite par un champ de référence dédié. « same_procedure_different_lot » protège les objets auxquels on peut répondre séparément. « related_process » relie accord-cadre, marché subséquent, renouvellement ou remplacement sans fusion. « probable_match_review » garde un rapprochement plausible en attente. « distinct_opportunity », « identity_conflict » et « insufficient_identity » interdisent la réduction automatique. L’interface peut regrouper des représentations confirmées; aucune observation source n’est supprimée.

## Problème

Une consultation française peut être décrite au BOAMP, au JOUE par TED, sur PLACE ou un autre profil d’acheteur, puis reprise par plusieurs services de veille. Le même avis produit alors plusieurs cartes. Pourtant, un intitulé presque identique peut aussi désigner un nouveau millésime, un lot différent, un avis rectificatif ou l’attribution du marché. Le BOAMP conserve des identifiants d’annonce, des références de procédure et parfois des annonces antérieures; eForms sépare procédure, avis et version. Un filtre fondé sur le titre et l’acheteur ignore ces portées. Il peut compter quatre fois la même publication ou masquer le seul événement qui modifie la réponse.

## Point de vue

Posez d’abord la question au bon niveau. L’identifiant BOAMP « idweb » retrouve une annonce BOAMP. Un « contractfolderid » eForms, lorsqu’il est présent, relie des publications d’une procédure. L’identifiant d’avis eForms et sa version décrivent une publication plus étroite; le lot en limite l’objet. Les annonces liées ou antérieures forment des relations, pas des égalités. Conservez schéma, producteur, valeur brute, type d’avis, date de parution et source. Acheteur, objet, CPV, lieu, valeur et date servent à tester la cohérence. Un agent peut établir le graphe depuis des sources publiques. Il ne doit pas supprimer une ligne, transformer un rectificatif en copie, réunir deux lots ou annoncer un remplacement sans référence officielle.

## Deux résultats identiques à l’écran peuvent demander des décisions différentes

Le mot « doublon » est trop large pour une donnée de marché public. Deux URL peuvent afficher une publication identique. Deux versions peuvent appartenir au même avis. Deux avis peuvent jalonner la même procédure. Deux lignes peuvent représenter des lots différents. Enfin, deux publications liées peuvent demander des actions différentes au candidat. La fiche répond séparément à chacun de ces niveaux.

Le cas le plus étroit est la reprise d’une même publication. Il faut la même identité d’avis, la même version et le même périmètre, confirmés par le contenu. Une page HTML, un document PDF, une réponse d’API et une page de profil d’acheteur peuvent la représenter. L’interface peut n’afficher qu’une carte principale, à condition de garder chaque source et ses écarts accessibles.

Le partage d’une procédure dit autre chose. Un avis de marché, un rectificatif et un avis d’attribution peuvent porter le même identifiant de procédure à des moments différents. Un avis eForms de préinformation n’en porte pas; l’avis ultérieur le relie par BT-125 et, si nécessaire, par BT-1251. Les objets se ressemblent parce que le besoin reste proche. Chaque avis conserve son identifiant, sa nature, sa date et son effet. La chronologie les réunit sans les réduire.

Le lot détermine souvent la réponse opérationnelle. Une seule publication peut contenir plusieurs prestations auxquelles les entreprises répondent séparément. Si un agrégateur fabrique une carte par lot, ces cartes ne sont pas des doublons pour la qualification. Si le numéro de lot a disparu, elles restent sous insufficient_identity jusqu’à la lecture de l’avis officiel.

**États de rapprochement pour deux annonces**

| État | Ce qui concorde | Traitement |
| --- | --- | --- |
| same_publication_representation | Avis, version et périmètre publié | Grouper la vue et garder les sources |
| same_notice_different_version | Identifiant d’avis, version différente | Conserver la chronologie éditoriale |
| same_procedure_related_event | Identifiant de procédure | Afficher chaque événement sous la procédure |
| same_procedure_different_lot | Procédure commune, lot différent | Garder les décisions de réponse séparées |
| related_process | Relation explicite entre procédures | Relier sans fusionner |
| probable_match_review | Indices cohérents, clé principale absente | Conserver et faire contrôler |
| identity_conflict | Clé forte contradictoire | Bloquer le regroupement |

## Le BOAMP fournit des clés d’annonce et des liens de procédure distincts

L’API ouverte du BOAMP attribue un « idweb » à chaque annonce et publie une « url_avis » qui permet de la retrouver. Pour des annonces eForms, le champ « contractfolderid » porte l’identifiant de procédure. Des champs d’annonces antérieures ou liées peuvent référencer d’autres « idweb », leur nature et leur publication. Ces données permettent de construire des liens plus précis qu’un rapprochement d’intitulés.

Deux enregistrements qui partagent un « contractfolderid » appartiennent à la même procédure eForms, mais peuvent annoncer la mise en concurrence, une modification ou le résultat. Comparez leur « idweb », leur nature, leur état, leur date de parution et leurs références. Deux « idweb » différents ne deviennent pas un seul avis parce qu’ils citent la même procédure. Ils occupent des nœuds distincts du graphe.

Un avis BOAMP et sa publication TED peuvent être deux représentations officielles d’un même événement. Le rapprochement exige les identifiants eForms, le numéro de publication, l’acheteur, la nature et les lots. Une concordance de texte ne suffit pas. Les traductions, limites de champ ou calendriers de diffusion peuvent produire des différences légitimes entre les pages.

Les anciens formats n’exposent pas toujours « contractfolderid ». Le BOAMP peut néanmoins fournir des annonces antérieures avec « idweb » et références JOUE. Utilisez ces relations telles qu’elles sont publiées. Si aucune clé forte ne relie deux annonces, gardez probable_match_review et indiquez la recherche publique qui pourrait résoudre le cas. Ne fabriquez pas un identifiant de procédure à partir du titre.

**Champs BOAMP utiles au rapprochement**

| Champ | Portée | Usage correct |
| --- | --- | --- |
| idweb | Annonce BOAMP | Identifier et rouvrir cette annonce |
| url_avis | Représentation publique | Contrôler le contenu de l’annonce |
| contractfolderid | Procédure eForms | Relier les événements d’un achat |
| nature et état | Fonction de l’annonce | Séparer marché, rectificatif et résultat |
| annonces antérieures | Relation publiée | Tracer la chronologie sans fusion |
| référence JOUE | Publication européenne | Rapprocher BOAMP et TED |
| lot | Partie de la procédure | Préserver les objets de réponse |

## Une procédure commune ne transforme pas ses avis en copies

eForms utilise BT-04 pour la procédure, BT-701 pour l’avis et BT-757 pour sa version. Les versions d’un même avis partagent BT-701, tandis que la version augmente à chaque nouvelle édition. Le numéro de publication est ajouté lors de la publication. Pour prouver une reprise exacte, comparez donc avis, version et publication. Pour prouver seulement l’appartenance à la procédure, BT-04 suffit.

Un avis de changement possède sa propre identité et désigne l’avis ainsi que la version qu’il modifie au moyen de BT-758. Cette référence orientée est plus informative qu’un indicateur de doublon. Elle permet de savoir quel texte a changé. L’avis initial reste nécessaire pour comprendre la base, et l’avis de changement devient nécessaire pour connaître la modification.

OCDS distingue aussi le processus et l’événement. L’OCID est unique pour un processus d’achat et relie des données publiées à plusieurs dates ou endroits. L’identifiant de release est unique à l’intérieur de cet OCID. Les releases sont immuables, alors que le record les compile. Un même OCID soutient un groupe de procédure, pas la suppression de toutes ses releases.

Les relations OCDS entre processus évitent un autre faux rapprochement. Un accord-cadre et un marché subséquent, une procédure de planification et plusieurs marchés, ou un contrat et son renouvellement peuvent porter des OCID différents reliés explicitement. Ils sont liés, mais restent des procédures distinctes avec leurs propres échéances, lots et décisions.

**Conclusions permises par chaque clé**

| Clé | Conclusion permise | Conclusion interdite |
| --- | --- | --- |
| BT-04 | Même procédure eForms | Même avis ou même lot |
| BT-701 | Même lignée d’avis | Même version |
| BT-701 avec BT-757 | Même édition eForms | Même route web |
| Numéro TED | Même publication au JOUE | Même action en cours |
| BT-758 | Avis et version modifiés | Publication identique |
| OCID | Même processus OCDS | Même release |
| OCID avec release ID | Même événement de données | Même rôle de source |
| Référence acheteur | Indice dans un espace donné | Identité mondiale |

## Le résultat doit expliquer chaque lien et chaque contradiction

La fiche de paire conserve les deux observations complètes, puis ajoute des arêtes typées. Chaque arête indique le niveau, la clé, son système, le champ source et la date de lecture. Une paire peut porter « même procédure » et « lot différent » en même temps. Les preuves contraires sont stockées à côté. Une décision finale sans ce détail ne permet pas à un autre agent de la contrôler.

La représentation préférée dépend de l’usage. Le BOAMP ou TED peut fournir le meilleur lien de publication; PLACE ou le profil d’acheteur peut être nécessaire pour les pièces et le dépôt. Le choix d’une carte principale ne déplace pas les responsabilités. Chaque valeur reste rattachée à la source qui la publie, avec son heure de vérification.

Un calcul textuel peut préparer le travail. Il rapproche objets normalisés, noms d’acheteurs, CPV, lieux, valeurs et fenêtres de dates. Sa sortie est une liste de candidats avec les composantes concordantes. Elle n’est jamais la décision elle-même. Une divergence de « idweb », de procédure ou d’acheteur légal pèse plus lourd qu’un titre presque identique.

Un agent peut lire l’API BOAMP, les avis TED et les pages publiques du profil d’acheteur. Il peut proposer un groupe de représentations et restituer toutes les URL. Il s’arrête si une clé forte diverge, si le lot manque ou si la nature de l’avis n’est pas établie. Il ne supprime pas de veille, ne crée pas de compte et ne contacte pas l’acheteur pour résoudre le rapprochement sans autorisation distincte.

**Structure minimale de la fiche de paire**

| Bloc | Contenu | Rôle |
| --- | --- | --- |
| observations | Producteurs, URL, identifiants et dates | Préserve les sources brutes |
| comparison_scope | Représentation, avis, procédure, lot, action | Limite le sens de “même” |
| identifier_edges | Système, valeur, portée et champ | Expose la preuve d’identité |
| relationship_edges | antérieur, changement, résultat ou processus lié | Conserve la chronologie |
| content_checks | Acheteur, nature, objet, lieu, valeur et date | Vérifie la cohérence |
| contradictions | Champ, valeurs et sources | Bloque une réduction risquée |
| decision | État, raison, réviseur et instant | Pilote l’affichage |
| view_policy | Carte préférée et sources associées | Sépare interface et preuve |
| recheck | Événement déclencheur et source suivante | Rouvre le groupe |

## Sept résultats cachent une procédure, trois avis et deux lots

Une métropole fictive publie un marché de maintenance énergétique sous l’identifiant de procédure 33333333-4444-4555-8666-777777777777. Le lot 1 concerne les bâtiments administratifs; le lot 2, les équipements sportifs. Le BOAMP et TED publient l’avis de marché. PLACE affiche une page de consultation et deux lignes de lot. Un service de veille reprend encore le titre général sans numéro de lot.

L’annonce BOAMP et la publication TED portent le même identifiant d’avis, la même version, le même numéro de publication, le même acheteur et les deux lots. Elles reçoivent same_publication_representation. La page PLACE est reliée à cette publication par la référence de consultation et les identifiants concordants, mais elle garde son rôle opérationnel. Ses deux lignes reçoivent same_procedure_different_lot et restent séparées pour la qualification.

Un rectificatif paraît ensuite avec son propre « idweb » et son propre identifiant d’avis. Il cite la version de l’avis qu’il modifie et conserve l’identifiant de procédure. La fiche lui attribue same_procedure_related_event. Après attribution, un troisième avis rejoint la même procédure. Aucun des deux ne compte comme nouvelle consultation ouverte, et aucun n’est caché comme copie.

La reprise commerciale sans lot partage le titre, l’acheteur et la référence. Elle reste probable_match_review jusqu’à ce que son lien ou son texte révèle le lot ou l’avis repris. L’interface peut la placer sous le groupe de procédure avec un avertissement, mais elle ne la supprime pas. Le graphe final montre trois avis, deux lots, plusieurs représentations et toutes les relations utilisées.

**Décisions pour le cas fictif**

| Paire | Relation | Conséquence |
| --- | --- | --- |
| BOAMP et TED pour l’avis initial | same_publication_representation | Une carte de publication, deux sources |
| Avis initial et rectificatif | same_procedure_related_event | Rectificatif conservé et relié |
| Avis initial et attribution | same_procedure_related_event | Résultat hors des offres ouvertes |
| PLACE lot 1 et lot 2 | same_procedure_different_lot | Deux décisions de candidature |
| Reprise commerciale sans lot | probable_match_review | Visible jusqu’au contrôle |
| Annonce avec autre procédure | identity_conflict | Regroupement interdit |

## Résultats utiles

- Chaque paire reçoit une conclusion distincte pour la représentation, l’avis, la procédure, le lot et l’action de réponse.
- Les reprises BOAMP, TED et profil d’acheteur peuvent partager un groupe d’affichage sans perdre leurs rôles ni leurs liens.
- « idweb », identifiant de procédure, identifiant d’avis, version, publication TED et lot gardent leur portée propre.
- Rectificatifs, attributions et autres annonces liées restent visibles dans une chronologie de procédure.
- Des lignes correspondant à plusieurs lots ne sont jamais éliminées de la qualification par une règle de titre.
- Une divergence d’identifiant fort, d’acheteur ou d’objet bloque le regroupement automatique.
- Les rapprochements sans clé suffisante restent affichés avec leur preuve et leur prochain contrôle.
- Une autre personne ou un agent peut reproduire la décision à partir de la fiche de paire.

## Déroulement

1. **Nommer le niveau comparé.** Précisez si l’on cherche la même représentation, le même avis et sa version, la même procédure, le même lot ou la même action de candidature.
2. **Conserver les deux observations.** Enregistrez producteur, URL, date de lecture, langue, libellés et identifiants bruts avant toute normalisation. Aucun champ ne doit migrer silencieusement d’une source à l’autre.
3. **Comparer les clés dans leur système.** Rapprochez « idweb », procédure eForms, avis, version, numéro TED, référence acheteur et lot seulement avec leur schéma et leur portée.
4. **Lire les liens publiés.** Relevez nature et état de l’avis, annonces antérieures, avis liés, référence de l’avis modifié et relations OCDS. Un lien explicite domine une ressemblance textuelle.
5. **Délimiter ce qui se soumissionne.** Comparez lots, prestations, zones, formes de réponse et échéances. Déterminez si le candidat doit prendre une décision ou plusieurs.
6. **Tester les champs descriptifs.** Normalisez objet, acheteur, CPV, lieu, valeur et dates pour trouver des candidats et des contradictions. Gardez toujours le texte original.
7. **Attribuer une relation contrôlée.** Choisissez l’état le plus étroit que les preuves soutiennent, listez accords et écarts, puis indiquez ce qui manque encore.
8. **Regrouper sans effacer.** Désignez une représentation préférée pour l’affichage, gardez les autres sources, versions, événements et lots, et rouvrez la fiche à chaque nouveau lien officiel.

## Décisions clés

- À quel niveau les deux résultats doivent-ils être identiques pour l’usage prévu?
- Les valeurs « idweb », avis, version, procédure et publication TED concordent-elles dans leurs systèmes respectifs?
- La paire partage-t-elle seulement une procédure tout en portant deux natures d’avis différentes?
- Des lots distincts créent-ils des périmètres, conditions ou réponses séparés?
- Une annonce cite-t-elle l’autre comme avis antérieur, rectifié, remplacé ou lié?
- L’acheteur, l’objet, le lieu, la chronologie et la voie de réponse sont-ils compatibles avec la relation proposée?
- Quelle source doit apparaître en premier sans recevoir l’autorité sur les champs des autres?
- Quel identifiant absent ou contradictoire impose une revue avant de masquer un résultat?

## Risques

- Un marché récurrent peut reprendre le même intitulé chaque année tout en créant une nouvelle procédure.
- Un même identifiant de procédure peut relier avis de marché, rectificatif et résultat sans les rendre interchangeables.
- Une version publiée peut disparaître derrière une observation préparatoire dont le contenu est presque identique.
- Plusieurs lots peuvent exiger des capacités, prix, partenaires ou dépôts distincts.
- Une reprise commerciale peut tronquer les lots ou conserver une date devenue ancienne.
- Une référence de consultation peut être réutilisée par un autre acheteur ou un autre millésime.
- Un score de similarité peut cacher qu’aucune clé officielle ne concorde.
- Un agent peut retirer du suivi une annonce liée avant d’avoir compris son effet sur la candidature.

## Indicateurs

- paires avec une conclusion explicite aux niveaux représentation, avis, procédure, lot et action
- rapprochements appuyés par une clé qualifiée ou une relation officielle publiée
- versions, natures d’avis et lots conservés après regroupement de l’affichage
- rapprochements probables maintenus visibles jusqu’à leur revue
- conflits indiquant le champ exact, les deux valeurs et leurs producteurs
- représentations préférées reliées à toutes les observations BOAMP, TED et profil d’acheteur
- décisions reproduites sans relancer un calcul opaque de similarité
- groupes rouverts après nouvel avis, version, lot ou correctif de source

## Questions fréquentes

### Le même titre et le même acheteur prouvent-ils un doublon?

Non. Les marchés récurrents et les lots reprennent souvent ces éléments. Cherchez les identifiants d’avis, de version, de procédure, de publication et de lot.

### Deux annonces avec le même « contractfolderid » sont-elles identiques?

Elles appartiennent à la même procédure eForms. Comparez leur « idweb », identifiant d’avis, version, nature et lots pour connaître leur relation exacte.

### Un rectificatif peut-il être masqué comme doublon?

Non. Il possède sa propre identité et modifie un avis ou une version désignée. Gardez-le comme événement lié dans la chronologie.

### Le BOAMP et TED peuvent-ils afficher la même publication?

Oui. Vérifiez les identifiants eForms, le numéro de publication, l’acheteur, la nature et les lots avant de les regrouper comme représentations.

### Faut-il supprimer la ligne d’un agrégateur après avoir trouvé l’avis officiel?

Gardez-la comme observation secondaire reliée à l’avis. Elle documente la découverte et permet de mesurer les champs manquants, anciens ou mal rapprochés.

### Comment traiter deux lignes sans numéro de lot?

Conservez-les comme rapprochements probables et consultez l’avis officiel. Ne décidez pas qu’elles sont identiques tant que le périmètre de lot reste absent.

### Un score de similarité peut-il suffire?

Il peut classer les paires à examiner. La réduction exige des clés qualifiées, des relations publiées et un contrôle du périmètre avec les contradictions visibles.

### Quand faut-il rouvrir une décision de rapprochement?

Lorsqu’un nouvel avis, une version, un lot, une annonce liée, un changement de source ou une contradiction d’identifiant apparaît.


## Sources primaires

- [API officielle du Bulletin des annonces des marchés publics](https://www.data.gouv.fr/dataservices/api-bulletin-officiel-des-annonces-des-marches-publics-boamp), Direction de l’information légale et administrative
- [Données ouvertes BOAMP et champs de rapprochement](https://boamp-datadila.opendatasoft.com/api/explore/v2.1/catalog/datasets/boamp/records?limit=1), Direction de l’information légale et administrative
- [PLACE et les fonctions du profil d’acheteur](https://www.economie.gouv.fr/dae/les-projets-achats-les-consultations/place-la-plateforme-des-achats-de-letat), Direction des achats de l’État
- [Identifiants de procédure, d’avis et de version eForms](https://docs.ted.europa.eu/eforms/latest/schema/all-in-one.html), Office des publications de l’Union européenne
- [Liens entre avis d’une même procédure eForms](https://docs.ted.europa.eu/eforms-common/FAQ/index.html), Office des publications de l’Union européenne
- [Avis de changement et référence à la version modifiée](https://docs.ted.europa.eu/eforms/latest/schema/change-notice.html), Office des publications de l’Union européenne
- [Portée des identifiants OCDS](https://standard.open-contracting.org/latest/en/schema/identifiers/), Open Contracting Partnership
- [Releases, lots et processus liés dans OCDS](https://standard.open-contracting.org/latest/en/schema/reference/), Open Contracting Partnership


## Articles complémentaires

- [Surveiller un acheteur et ses entités liées](https://zephior.com/fr/insights/monitor-a-buyer-and-its-subsidiaries)
- [Tous les lots ont-ils la même date limite ?](https://zephior.com/fr/insights/verify-lot-level-tender-deadlines)
- [Automatisation de l’enrichissement avec provenance par champ](https://zephior.com/fr/solutions/data-enrichment-automation)
- [Cette preuve couvre-t-elle vraiment l’affirmation de l’offre ?](https://zephior.com/fr/insights/verify-the-scope-of-proposal-evidence)