Une fiche de réouverture associe l’identité publique d’un marché à un chemin contrôlé pour le retrouver. Elle conserve le producteur de l’avis, le rôle de chaque portail, l’identifiant de procédure, l’identifiant et la version de l’avis, le numéro de publication, le lot, la référence de consultation, l’URL publique, la représentation de données, la date de contrôle et une procédure de recherche de secours. « public_locator_verified » exige une ouverture anonyme et une concordance des identifiants. « public_recovery_verified » signifie qu’une recherche publique reproduit le bon résultat malgré l’absence de lien direct fiable. « authenticated_route_only » décrit la frontière où commence l’espace réservé, sans enregistrer son URL de session. « temporary_locator_rejected » écarte une adresse signée, temporaire ou porteuse d’accès. « identity_mismatch », « source_conflict » et « source_unavailable » bloquent la réutilisation si la cible est différente, contradictoire ou invérifiable. « superseded » relie la fiche qui remplace celle-ci. Aucun de ces états ne confirme que la consultation reste ouverte.
En France, un même achat peut laisser une trace au BOAMP, une publication au JOUE, une consultation sur PLACE et des documents accessibles depuis un profil d’acheteur. Chaque site remplit une fonction. L’adresse copiée après plusieurs clics peut contenir l’état d’une recherche, une session, un ticket de téléchargement ou une route interne à l’application. Elle fonctionne encore dans le navigateur de la personne qui l’a copiée, puis renvoie un collègue vers l’accueil ou la connexion. À l’inverse, certaines URL publiques comportent une requête parfaitement légitime, par exemple un identifiant d’avis BOAMP. Supprimer tous les paramètres détruirait alors le bon lien. La fiche doit reconnaître la sémantique de la route et préserver l’identité hors de celle-ci.
Pour un avis français, conservez d’abord les identifiants fournis par le producteur. L’API officielle BOAMP expose notamment « idweb », l’identifiant de procédure eForms lorsqu’il existe, l’état, les avis liés et une « url_avis » publique. Le portail PLACE permet de consulter les consultations de l’État et sépare l’accès public de certaines actions authentifiées. Utilisez ces sources pour construire deux chemins: la publication vérifiable et l’entrée opérationnelle. Contrôlez le lien sans cookie, puis comparez identifiant, acheteur, nature d’avis et lot. Un agent peut lire l’API ouverte, suivre une URL publique et produire une recette de recherche. Il ne doit pas se connecter, accepter des conditions, réutiliser un jeton, télécharger un dossier restreint ou déposer un pli sans autorisation distincte.
Réponse directe
Le bon livrable contient une identité et un chemin public
Conservez l’URL seulement après un test anonyme. La fiche doit aussi contenir les identifiants qui permettent de reconnaître l’avis indépendamment de l’adresse: producteur, procédure, avis, version, publication, acheteur et lot. Si l’URL disparaît, ces clés permettent de refaire une recherche. Si elle mène ailleurs, elles révèlent immédiatement l’erreur.
L’adresse visible raconte le parcours du navigateur. Elle peut inclure une sélection temporaire, une langue, une position dans la liste, un identifiant public ou un accès secret. RFC 3986 autorise requêtes et fragments dans une URI; leur seule présence ne tranche rien. Il faut connaître la fonction donnée par le producteur à chaque composant et refuser les valeurs qui représentent une session ou un droit d’accès.
Le contrôle part d’un profil sans cookies. Il suit les redirections puis cherche les preuves d’identité dans la réponse. Une page de connexion en statut 200 échoue au test. Une page d’accueil sur le bon domaine échoue aussi. L’avis est retrouvé lorsque les identifiants, l’acheteur et la nature correspondent. Le titre seul reste insuffisant.
La réouverture ne valide pas l’état juridique ou opérationnel du marché. Un avis initial peut rester public après un rectificatif, une annulation ou l’expiration du délai. Gardez l’adresse de la publication citée et reliez les publications suivantes. Une vérification distincte décide du document courant et de l’ouverture de la procédure.
| État | Preuve minimale | Action admise |
|---|---|---|
| public_locator_verified | Ouverture anonyme et identité concordante | Partager avec date de contrôle |
| public_recovery_verified | Recherche publique reproductible | Partager la recette de recherche |
| authenticated_route_only | L’action exige un compte autorisé | Décrire la frontière sans URL privée |
| temporary_locator_rejected | Session, signature ou expiration détectée | Écarter la valeur et repartir de l’identifiant |
| identity_mismatch | La cible désigne un autre objet | Bloquer la réutilisation |
| source_unavailable | La source ne peut pas être contrôlée | Prévoir un contrôle manuel ou différé |
Cas français
L’avis BOAMP et la consultation PLACE ne sont pas le même objet web
La DILA met l’API BOAMP à disposition gratuitement pour la réutilisation des annonces. Les données actuelles exposent un « idweb » tel que « 26-85239 », une « url_avis » publique construite avec cet identifiant et, pour certains avis, un « contractfolderid » issu de la procédure eForms. Elles peuvent aussi indiquer l’état et les annonces liées. Ces champs donnent une base contrôlable pour retrouver la publication sans conserver la session d’un moteur de recherche.
La Direction des achats de l’État décrit PLACE comme la plateforme gratuite où les entreprises consultent les marchés de l’État, retirent des documents, répondent et échangent avec les acheteurs. La consultation publique et les actions identifiées ne portent pas le même niveau d’accès. Une fiche peut donc avoir « public_locator_verified » pour l’avis BOAMP, « public_recovery_verified » pour l’entrée de consultation PLACE et « authenticated_route_only » pour la messagerie ou le dépôt.
Le lien BOAMP contient une requête « q=idweb:... ». Elle sélectionne un identifiant public fourni dans les données officielles. La conserver est justifié par la sémantique du producteur et par le test du contenu. À l’opposé, un lien reçu après connexion à PLACE peut comporter un état de session ou une route interne. N’essayez pas de transformer ce dernier en lien public en retirant au hasard ce qui ressemble à un jeton.
Le BOAMP et TED restent des publications, pas des substituts à toutes les fonctions du profil d’acheteur. Les documents de consultation, les réponses aux questions et l’interface de dépôt peuvent exiger le portail désigné. La fiche de réouverture conserve la publication vérifiable et le chemin autorisé vers ce portail, avec une frontière explicite entre lecture publique et action au nom de l’entreprise.
| Champ | Source | Fonction |
|---|---|---|
| idweb | API BOAMP | Retrouver l’annonce BOAMP |
| url_avis | API BOAMP | Ouvrir la représentation publique testée |
| contractfolderid | Avis eForms si présent | Relier les publications de procédure |
| état et annonces liées | API BOAMP | Déclencher une revue de lignée |
| référence de consultation | PLACE ou documents | Rechercher l’espace opérationnel |
| lot | Avis et règlement | Vérifier l’objet récupéré |
| frontière d’accès | Observation contrôlée | Empêcher une action non autorisée |
Clés de récupération
Chaque identifiant répond à une question différente
L’identifiant de procédure relie les étapes d’un même achat. L’identifiant d’avis et sa version fixent une publication eForms. Le numéro de publication TED permet d’appeler une représentation publiée selon la route directe documentée par l’Office des publications. « idweb » retrouve l’annonce BOAMP. La référence interne de l’acheteur aide à ouvrir la consultation sur son portail. Conservez tous ceux qui existent avec leur système et leur libellé.
Les relations comptent autant que les valeurs. Un avis rectificatif n’est pas une nouvelle version silencieusement posée sur l’ancienne page. Il possède sa propre identité et réfère à l’avis modifié. L’API BOAMP peut signaler des annonces liées. Dans OCDS, un OCID regroupe les publications d’un processus tandis que chaque release conserve un événement daté. Une fiche utile représente ces liens au lieu de remplacer l’identifiant initial par le plus récent.
Une URL canonique apporte une autre information. RFC 6596 la définit comme la représentation préférée parmi des contenus dupliqués et cite le retrait des identifiants de session comme cas courant. Contrôlez que la cible contient le même avis. Le producteur peut déclarer une cible erronée, ou une application peut générer une URL canonique trop générale. Cette relation guide le choix du lien sans remplacer les clés métier.
Le jeu de concordance doit rester lisible. Pour une annonce BOAMP, comparez « idweb », acheteur, nature, date de parution et objet. Pour TED, comparez numéro de publication, UUID de l’avis, version, type et procédure. Pour PLACE, ajoutez la référence de consultation et le lot. Une incohérence sur un identifiant fort produit « identity_mismatch », même si les titres semblent proches.
| Clé | Portée | Erreur évitée |
|---|---|---|
| idweb BOAMP | Annonce BOAMP | Confondre deux annonces proches |
| Identifiant eForms | Lignée d’un avis | Perdre la version contrôlée |
| Version eForms | Édition de l’avis | Citer un autre état éditorial |
| Numéro TED | Publication au JOUE | Copier une URL de recherche TED |
| Identifiant de procédure | Ensemble du processus | Manquer les publications liées |
| Référence acheteur | Espace opérationnel | Supposer une unicité mondiale |
| Lot | Partie du besoin | Récupérer le bon avis mais le mauvais objet |
Contrôle technique
Le test vérifie le contenu sans transporter la session
OWASP explique qu’un identifiant de session placé dans une URL peut se retrouver dans les liens, les journaux, l’historique, les favoris, l’en-tête de provenance et les moteurs de recherche. Une fiche partagée multiplie ces chemins de fuite. Lorsqu’une adresse semble contenir une valeur d’accès, n’enregistrez pas la chaîne complète dans un rapport de test. Décrivez le type de risque et revenez à la publication publique.
Une liste noire de mots comme « token » ou « session » ne suffit pas. Les portails choisissent librement leurs noms de paramètres, et un identifiant opaque peut être sensible. Construisez plutôt une liste blanche des routes publiques documentées par chaque producteur. Tout autre motif reçoit « temporary_locator_rejected » jusqu’à ce qu’une documentation ou un test public indépendant établisse sa fonction.
Le contrôle anonyme suit les redirections autorisées et enregistre leur statut selon RFC 9110. Une redirection permanente signale une intention de déplacement, mais elle ne prouve pas l’identité de la cible. Relisez les identifiants après le dernier saut. Une redirection temporaire peut dépendre de la langue, d’une maintenance ou d’un répartiteur. Gardez la chaîne observée et ne remplacez l’URL recommandée qu’après validation.
Certains portails bloquent les clients automatisés, limitent la fréquence ou demandent un défi anti-robot. Dans ce cas, « source_unavailable » décrit le résultat exact. La fiche fournit l’identifiant et la procédure manuelle publique. Elle ne contourne pas le contrôle et ne déclare pas la disparition de l’avis. Un humain peut valider le contenu dans un navigateur autorisé.
| Observation | Interprétation | Suite |
|---|---|---|
| 200 et identifiants concordants | Localisateur public vérifié | Conserver la date et le type de contenu |
| 200 avec connexion | Espace authentifié | Chercher la publication ou l’entrée publique |
| 200 sur page d’accueil | Identité non retrouvée | Utiliser la recherche par identifiant |
| 301 ou 308 vers même avis | Déplacement permanent possible | Valider puis mettre à jour la route recommandée |
| 302 ou 307 contextuel | Redirection temporaire | Garder la route source et noter la chaîne |
| 403 ou défi robot | Source indisponible pour ce client | Contrôle manuel, aucun contournement |
| 404 avec recherche réussie | Ancien détail retiré | Passer à public_recovery_verified |
Exemple travaillé
Réparer une fiche française qui ne contient qu’un lien PLACE expiré
Une société fictive retient une consultation de fournitures publiée au BOAMP et hébergée sur PLACE. La personne chargée de la veille ouvre les documents après connexion et colle l’adresse du navigateur dans le CRM. Elle note aussi la référence « MINECO-2026-118 », mais ni « idweb » ni identifiant eForms. Le lendemain, le lien mène ses collègues à l’écran de connexion sans sélectionner la consultation.
La réparation commence par l’API BOAMP. Une recherche sur l’acheteur, l’objet et la date retrouve l’annonce. La fiche enregistre son « idweb », son « url_avis », son éventuel identifiant de procédure, son état et les annonces liées. L’URL est ouverte dans un contexte vierge. « idweb », acheteur et nature concordent, donc la publication reçoit « public_locator_verified ». Toute chaîne provenant de la session PLACE est supprimée des champs partagés.
La référence « MINECO-2026-118 » est ensuite testée depuis la recherche publique de PLACE. Le résultat attendu porte le même acheteur et le même objet. La fiche décrit le champ utilisé et l’entrée publique. L’accès au retrait identifié, à la messagerie ou au dépôt demeure « authenticated_route_only ». Une personne habilitée continuera avec son propre compte, sans que la fiche lui transmette la session d’un tiers.
Cette consultation, l’acheteur et la référence sont inventés. Le livrable obtenu permet de retrouver l’avis et le point d’entrée PLACE. Il ne prouve ni la présence de toutes les pièces, ni la version courante du règlement, ni l’ouverture du dépôt. Ces contrôles suivent leurs propres sources et dates.
| Bloc | Preuve conservée | Limite |
|---|---|---|
| Publication BOAMP | idweb, url_avis, acheteur, nature, contrôle | Ne remplace pas le profil d’acheteur |
| Lignée | procédure, état et annonces liées | Actualité à vérifier séparément |
| Entrée PLACE | page publique, champ et référence | Seulement jusqu’à la frontière de connexion |
| Espace réservé | authenticated_route_only | Aucune session partagée |
| Lien rejeté | type de risque sans valeur secrète | Ne pas rejouer ni journaliser |
| Prochaine action | contrôle des pièces et rectificatifs | Nouvelle autorisation si connexion nécessaire |
Ce qui caractérise un bon résultat
Résultats concrets pour lien fiable appel d’offres
- La fiche distingue le BOAMP ou TED comme publication et PLACE ou le profil d’acheteur comme espace opérationnel.
- Les valeurs « idweb », procédure, avis, version, publication, lot et référence interne gardent leur nom et leur portée.
- L’URL publique a été ouverte sans compte ni cookies et son contenu confirme l’identité attendue.
- Un paramètre public documenté n’est pas supprimé par réflexe, tandis qu’un jeton de session ne quitte jamais son contexte.
- Une recherche de secours précise le portail, le champ, la valeur et les contrôles à effectuer.
- Les avis rectificatifs et liés restent attachés à la publication citée sans la réécrire.
- Les accès aux documents, à la messagerie et au dépôt possèdent des états d’autorisation séparés.
- Une autre personne ou un agent peut reproduire le chemin avec la fiche seule.
Modèle opératoire
Comment exécuter le travail
- 01
Qualifier chaque site
Identifiez le producteur de l’avis, le support de publication, le profil d’acheteur, le portail documentaire et la voie de dépôt. Ne déduisez pas le rôle du seul nom de domaine.
- 02
Relever les identifiants bruts
Copiez les valeurs avec le libellé du champ, le système, la version et la date de lecture. Gardez « idweb » distinct de la référence de consultation et de l’identifiant eForms.
- 03
Choisir le localisateur public
Préférez l’URL publiée dans les données officielles, une route directe documentée ou la cible canonique déclarée par le producteur.
- 04
Écarter tout secret
Examinez localement chemin, requête et fragment. Ne placez dans aucune sortie partagée une session, une signature, un ticket, une valeur d’autorisation ou une date d’expiration liée à un accès.
- 05
Ouvrir en contexte vierge
Contrôlez sans connexion. Notez statuts, redirections, hôte final, type de contenu et concordance de l’identifiant, de l’acheteur et de la nature de l’avis.
- 06
Écrire le chemin de secours
Indiquez la page publique de recherche, le champ exact, la valeur, le résultat attendu et les éléments qui excluent un homonyme.
- 07
Tracer les avis liés
Conservez rectificatifs, remplacements et résultats comme publications distinctes. Un lien stable vers l’avis initial ne doit pas masquer leur existence.
- 08
Limiter l’action de l’agent
Autorisez la lecture publique et le compte rendu. Réservez connexion, retrait identifié, messagerie et dépôt aux personnes ou systèmes expressément habilités.
Évaluation
Les questions qui changent la décision
- Quel avis, quelle version et quel lot la fiche doit-elle reproduire?
- Le domaine consulté publie-t-il l’avis ou héberge-t-il seulement les opérations de la consultation?
- Quelle valeur est l’identifiant BOAMP, l’identifiant eForms, la référence acheteur ou le numéro TED?
- Le producteur expose-t-il une « url_avis », une route directe ou une cible canonique?
- La requête contient-elle un identifiant public documenté ou une valeur qui accorde un accès temporaire?
- Une ouverture anonyme retrouve-t-elle le même acheteur, la même nature et le même lot?
- Le lien vise-t-il une publication figée ou une vue courante susceptible d’intégrer des changements?
- Quel contrôle doit être répété après un rectificatif, une migration ou une redirection différente?
Modes d’échec
Où les équipes perdent le contrôle
Une URL PLACE copiée après connexion peut exposer un contexte d’accès ou ne fonctionner que pour son auteur.
Une réponse 200 peut afficher l’accueil, la connexion ou une application vide sans l’avis recherché.
Un paramètre « idweb » public peut être supprimé comme s’il s’agissait d’une session, rendant le lien inutilisable.
La référence de consultation peut être prise pour un identifiant global et retrouver un homonyme chez un autre acheteur.
Un lien de téléchargement signé peut être publié à la place de la page de l’avis.
L’avis initial peut rester accessible alors qu’un rectificatif modifie la date ou la portée.
Une copie locale peut être citée comme source actuelle après modification officielle.
Un agent peut créer un compte ou retirer des documents en mode identifié simplement pour achever son test.
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.
- fiches avec producteur, rôles des portails, identifiants typés et heure de contrôle
- ouvertures anonymes confirmant « idweb » ou identifiant d’avis, acheteur et nature
- URL partagées sans session, signature, ticket, autorisation ni valeur d’expiration
- recherches de secours reproduites sans compte ni panier enregistré
- publication, documents, messagerie et dépôt représentés par des routes distinctes
- avis liés et rectificatifs conservés sans écrasement de la publication citée
- écarts d’identité et sources indisponibles qui arrêtent les actions dépendantes
- contrôles renouvelés après changement d’avis ou de portail
Questions
Questions fréquentes
Une URL avec « ?q= » est-elle forcément temporaire?
Non. Le BOAMP publie une « url_avis » qui utilise une requête fondée sur « idweb ». Vérifiez la documentation du producteur et le contenu, sans supprimer le paramètre par réflexe.
Puis-je partager le lien affiché après ma connexion à PLACE?
Pas comme lien public, sauf fonction de partage explicitement prévue et testée sans votre session. Conservez plutôt la référence et le chemin depuis la recherche publique.
Quel identifiant BOAMP faut-il garder?
Gardez « idweb » avec « url_avis », acheteur, nature et date. Ajoutez l’identifiant de procédure eForms, la version et les avis liés lorsqu’ils sont disponibles.
Un numéro de consultation PLACE est-il universel?
Non. Traitez-le comme une référence dans le contexte du portail et de l’acheteur. Les identifiants BOAMP, TED ou eForms fournissent d’autres portées.
Le code 200 confirme-t-il la présence de l’avis?
Non. Comparez les identifiants et l’acheteur dans la page. Une connexion ou une page générale peut également répondre avec 200.
Que faire d’un téléchargement signé?
Ne le publiez pas comme URL durable. Conservez le lien public vers l’avis ou la consultation et décrivez le document avec son nom, sa date et son empreinte si la politique l’autorise.
Le lien BOAMP suffit-il pour déposer une offre?
Non. Il prouve la publication. Le règlement et le profil d’acheteur désignent la voie de retrait, de communication et de dépôt.
Un agent peut-il se connecter pour vérifier la consultation?
Seulement avec une autorisation distincte et des identifiants prévus pour lui. Sans cela, il s’arrête à la frontière publique et fournit une procédure de contrôle humain.
Sources
Sources primaires
- API certifiée du Bulletin officiel des annonces des marchés publics Direction de l’information légale et administrative
- Données ouvertes BOAMP et champs de récupération Direction de l’information légale et administrative
- PLACE, plateforme des achats de l’État Direction des achats de l’État
- Accès aux documents et authentification sur PLACE Ministère de l’Économie, des Finances et de la Souveraineté industrielle et numérique
- Liens directs TED et interface publique de recherche Office des publications de l’Union européenne
- Identifiants et versions des avis eForms Office des publications de l’Union européenne
- Identifiants et publications OCDS Open Contracting Partnership
- Risque des identifiants de session dans les URL OWASP Foundation
- RFC 3986 sur la syntaxe des URI RFC Editor
- RFC 6596 sur la relation canonique RFC Editor
- RFC 9110 sur les redirections HTTP 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.