Public Procurement Features

The public procurement platforms developed by SOGESTI (often known as e-Public Markets) are designed to cover the entire life cycle of a market from publication to award.

Here are the main features generally present in their solutions:

1. Management of Publications (Buyer side)

Assisted Writing: Creation of Advertising Notices (AAPC) with structured forms that meet regulatory standards.
Multi-support publication: Automatic dissemination on the buyer profile and, as required, to legal ad logs (JAL) or BOAMP.
DCE Management: Secured e-mailing of the Business Consultation Record (BCD) with tracking of downloads. [1, 2, 3]

2. Business Space (Applicant side)

Multicriteria search: Search engine by keywords, CPV codes, geographical area and closing date.
Custom e-mail alerts: A monitoring system allowing companies to receive notifications as soon as a market matches their profile.
Secure electronic deposit: Possibility to submit a dematerialized offer with guaranteed time stamp (evidence value). [4, 5, 6, 7, 8]

3. Analysis and Attribution

Opening of folds: Secure procedure allowing simultaneous opening of bids by the commission, guaranteeing confidentiality until the deadline.
Tools for analysis: Comparison tables of bids and management of selection stages (eligibility of applications, review of tenders).
Automatic notifications: Dematerialized delivery of rejection letters to unsuccessful candidates and notice of award to successful tenderer.

4. Security and Compliance

Electronic Signature: Integration of eIDAS or RGS-compliant signature modules** to authenticate the documents.
Full Traceability: Audit Trail recording every action taken on the platform to ensure transparency and prevent corruption.
Evidence-based archiving: Secure retention of folds and exchanges during legal recourse periods. [9, 10, 11]

5. Pilotage and Monitoring

Scoreboard: Statistical monitoring of ongoing procedures and amounts committed.
Interfacing (API): Ability to link the platform to financial management tools or open national data portals (Open Data). [11]

For a public procurement platform such as SOGESTI, the electronic signature must guarantee the identity of the signatory and the integrity of the documents (offer, act of undertaking, commission ticket).

The following are the types of certificates and compatible signing standards:

1. The types of certificates admitted

In France and Europe, dematerialization platforms generally accept two levels of certificates:

RGS (General Security Officer): RGS certificates** (2 stars) are the historical standard for exchanges with the French administration.
eIDAS (European Regulation): This is the current standard. Certificates « Qualified » (issued on physical media such as a cryptographic USB stick or smart card) are mandatory for signatures having the same legal value as a handwritten signature.

2. Supported signature formats

Modern platforms manage several signed file formats:

PADES (PDF Advanced Electronic Signature) : The most common. The signature is integrated directly into the PDF file (visible with Adobe Reader).
XAdES (XML Advanced Electronic Signature): Used to sign structured data or attached files via a separate XML file.
CAdES (CMS Advanced Electronic Signature) : Utilisé pour signer n’importe quel type de fichier (crée une enveloppe .p7m).

3. Comment ils sont intégrés à l’application

Pour une solution basée sur Drupal, l’intégration ne se fait pas directement dans le code source mais via des services tiers :

API de Signature (ex: Universign, Yousign, DocuSign) : L’application envoie le document à signer à l’API, qui gère l’authentification forte du signataire (souvent via un code SMS ou une vérification de clé matérielle) et renvoie le document scellé.
Applet ou Extension de navigateur : Pour les signatures locales avec clé USB, la plateforme utilise souvent un petit composant (type Java ou extension Chrome) pour communiquer avec le certificat physique de l’utilisateur.

4. Vérification de la validité

La plateforme doit inclure un vérificateur de signature. Lorsqu’un candidat dépose un pli signé, le système vérifie automatiquement :

Que le certificat n’est pas expiré.
Que l’autorité de certification est reconnue (LSTL – Listes de confiance).
Que le document n’a pas été modifié après la signature.

L’intégration d’une API de signature (comme Yousign, Universign ou DocuSign) dans Drupal 11 pour un workflow de marchés publics se fait généralement via un service personnalisé qui communique avec l’API externe.

Voici les étapes techniques pour réaliser cette intégration :

1. Création d’un Service de Signature (Custom Service)

Ne mettez pas la logique d’appel API directement dans vos contrôleurs. Créez un service Drupal (src/SignatureService.php) pour centraliser les appels :

Authentification : Gestion de la clé API ou du token OAuth2.
Envoi du document : Envoi du fichier (PDF du marché ou acte d’engagement) vers l’API.
Récupération du statut : Vérification si le document est « en attente », « signé » ou « refusé ».

2. Déclenchement via ECA (Le « Low-Code »)

Plutôt que de coder tout le workflow, utilisez ECA pour appeler votre service au bon moment :

Événement : Le workflow passe à l’état « En attente de signature ».
Action : Appeler votre méthode de service sendDocumentToSign.
Résultat : L’ECA met à jour un champ « ID de signature externe » sur votre entité pour le suivi.

3. Gestion du Webhook (Le Retour d’Information)

C’est l’étape cruciale. L’API de signature doit prévenir Drupal dès que l’acheteur ou l’élu a signé.

Créez une Route personnalisée dans Drupal (/api/signature/callback).
Lorsque l’API appelle cette route, votre contrôleur :
1. Vérifie la signature de la requête (sécurité).
2. Télécharge le document final (le PDF scellé).
3. Met à jour l’état du marché en « Signé / Attribué ».
4. Déclenche l’envoi automatique du mail de notification au candidat retenu.

4. Stockage du « Preuve de Signature »

L’API vous renverra souvent un fichier de preuves (audit trail).

Utilisez un champ de type File configuré en « Private » pour stocker ce fichier.
Liez-le à l’entité du marché pour qu’il soit consultable uniquement par les administrateurs en cas de contrôle de la préfecture (contrôle de légalité).

5. Modules Drupal utiles pour l’intégration

External Entities : Si vous voulez manipuler les documents distants de l’API de signature comme s’il s’agissait de contenus Drupal locaux.
Key : Indispensable pour stocker vos clés d’API et secrets de manière sécurisée (hors de la base de données, par exemple dans des variables d’environnement).