Achats B2B : conception d’une plateforme de gestion des appels d’offres
Dealingi est venu pour une revue de design de maquettes terminées et est resté pour une refonte complète : des rôles et du cycle de vie de l’appel d’offres jusqu’aux enchères en direct, au responsive et au handoff.

Plateforme : web, de 1920 à 320 px.
Contexte : une revue devenue refonte
Dealingi est une plateforme B2B biélorusse où les entreprises achètent par appel d’offres et où les fournisseurs s’affrontent dans des enchères inversées. Un même utilisateur peut être acheteur et fournisseur — parfois le même jour.
L’équipe est arrivée avec une demande précise : un regard neuf sur des maquettes terminées avant le développement. La revue a montré que le problème ne tenait pas à des écrans isolés mais au modèle : l’interface décrivait une « page d’appel d’offres », alors que le produit avait besoin de l’appel d’offres comme processus — avec des rôles, des étapes et des embranchements.
Avant
Une seule page d’appel d’offres pour tous les cas. Ce que voient l’acheteur, le participant et le visiteur, et la façon dont l’écran change entre les candidatures et les enchères, n’était pas défini.
Après
L’appel d’offres est une machine à états. Chaque couple « rôle × étape » a son écran, son action principale et sa phrase sur ce qui se passe ensuite.

Étape 1. Revue de design
La revue a suivi trois couches, de l’ensemble vers le détail.
-
Parcours. Les chemins clés des deux rôles, de l’inscription à la transaction : là où le chemin s’interrompt ou oblige à deviner.
-
Heuristiques et cohérence. Visibilité du statut, prévention des erreurs, vocabulaire unique et patterns répétables.
-
Maturité pour le développement. États, écrans vides, erreurs, responsive — tout ce qu’un développeur inventerait sinon seul.
Les principaux constats :
- Pas de modèle de rôles. Les écrans ne distinguaient pas l’acheteur, le fournisseur, le participant et le visiteur.
- Pas d’étapes. Réception des candidatures, attente des enchères, enchères et clôture ressemblaient au même écran avec un autre texte.
- Embranchements non décrits. Et s’il n’y a aucune candidature ? Si une seule est approuvée ? Si le fournisseur n’a pas rempli son profil ?
- La création d’un appel d’offres tenait en une seule longue page. Les conditions de paiement et de livraison se perdaient parmi des dizaines de champs.
- Pas de système. Les composants étaient dessinés écran par écran, sans responsive.
Le tournant. La liste des constats a montré que des retouches ne suffiraient pas : il aurait fallu corriger chaque écran, et toujours sans logique commune. Nous avons convenu de reconcevoir la plateforme — et la revue est devenue le brief.
Étape 2. Recherche
Entretiens avec les parties prenantes — pour fixer les règles des enchères : le pas de baisse, le nombre minimal de participants, ce qui se passe en cas d’annulation.
Analyse concurrentielle de plateformes d’appels d’offres et d’enchères : comment elles affichent le statut, comment se dépose une candidature, ce qui se passe au moment des enchères.
Carte du cycle de vie de l’appel d’offres. Le livrable principal de l’étape : toutes les étapes, les transitions entre elles et ce que chaque rôle voit à chaque point.
| Étape | Acheteur | Fournisseur |
|---|---|---|
| Réception des candidatures | Invite, examine les candidatures, demande des documents | Étudie les conditions, candidate ou se retire |
| Attente des enchères | Voit les participants admis | Configure une enchère automatique |
| Enchères | Suit le déroulement | Enchérit à la baisse |
| Clôture | Confirme le gagnant, conclut la transaction | Voit le résultat : gagné ou perdu |
| Annulé / infructueux | Choisit un motif | Reçoit une notification qui l’explique |
Étape 3. Architecture et parcours
De la carte est née la navigation : sept sections au lieu d’un menu par type de page — accueil, catalogue des appels d’offres, mon espace, documents, mes achats, calendrier, chats.
Les parcours sont décrits séparément pour l’acheteur et le fournisseur, et les embranchements sont des écrans à part entière, pas des notes en marge :
- aucune candidature reçue — l’appel d’offres est annulé automatiquement ;
- une seule candidature approuvée — l’acheteur choisit : attribuer au prix de départ ou déclarer l’appel d’offres infructueux ;
- un fournisseur dont le profil est incomplet ne peut pas candidater — et voit précisément ce qui manque.
Swimlane : qui fait quoi, et quand
Tout le parcours d’un appel d’offres est réparti en couloirs — acheteur, fournisseur, plateforme. Un tel schéma montre d’emblée où un rôle attend l’autre et où le système doit agir seul : clôturer les candidatures, lancer les enchères, envoyer les notifications.
Le schéma se déplace et se zoome directement ici.
Décisions clés
1. Le tableau de bord évolue avec l’utilisateur
Le tableau de bord a quatre états : tout juste inscrit, profil rempli, adresses ajoutées, actif comme acheteur et fournisseur. Un nouveau venu voit la prochaine étape ; un utilisateur actif voit ses statistiques, les appels d’offres pertinents et les événements du lendemain.
2. Le catalogue répond à « cela vaut‑il la peine d’ouvrir ? »
La carte d’un appel d’offres porte le statut avec son échéance, un compte à rebours, le prix de départ avec et sans TVA, le nombre de lots et de participants. Une ligne à part explique pourquoi il vous est proposé : « 4 des 7 compétences de votre entreprise », « Correspond à votre spécialisation ».

3. Créer un appel d’offres : quatre étapes et un aperçu
Objet de l’appel d’offres, conditions de paiement, conditions de livraison, exigences envers les fournisseurs. La liste des étapes reste visible à droite, un brouillon peut être enregistré à chacune d’elles, et le total hors TVA est calculé automatiquement.
Étape 1. Objet de l’appel d’offres. Intitulé, dates et lots. Le formulaire calcule le nombre de jours entre la fin des candidatures et les enchères, et prévient que les candidatures non traitées seront rejetées automatiquement. Biens et services s’ajoutent un par un, directement dans le formulaire, sans fenêtre modale.

Import des lots. Personne ne saisit à la main un appel d’offres de quatre-vingts lots. La liste se charge depuis un CSV ou un Excel à partir d’un modèle prêt à l’emploi ; une erreur de format et une erreur dans le tableau sont des états distincts, chacun expliquant quoi corriger.

Étape 2. Conditions de paiement. Les conditions complexes se composent de choix simples : type de paiement, montant de l’acompte, événement qui le déclenche. Choisir un type ne révèle que les champs qui le concernent.

Étape 3. Conditions de livraison. Livraison ou retrait, une adresse du profil de l’entreprise ou une nouvelle, ajoutée sans quitter le formulaire. Le délai se fixe par une date ou par un nombre de jours.

Étape 4. Exigences envers les fournisseurs. Qui est admis — uniquement les assujettis à la TVA ou tout le monde — et pourquoi cela compte : un avertissement explique l’effet de ce choix sur la comparaison des prix. Les exigences se rédigent en texte ou se joignent en document. Vient ensuite un aperçu de l’appel d’offres vu par un fournisseur.

4. Les candidatures, l’établi de l’acheteur
Toutes les candidatures tiennent dans un tableau avec des onglets par statut. Depuis une ligne, l’acheteur peut accepter, refuser, ouvrir une candidature ou demander des documents complémentaires — sans passer par une page séparée.

5. Enchères : tout ce qui compte reste à l’écran
Pendant les enchères, un participant se pose trois questions : combien de temps reste-t‑il pour ce tour, quel est le prix actuel, et où sont mes offres dans le fil. Le minuteur, l’offre en cours, le pas et le numéro du participant sont réunis dans un bloc au‑dessus du fil ; les offres du participant sont surlignées, la nouvelle est signalée. Les participants sont anonymes — chacun n’a qu’un numéro.

Une offre en deux gestes. Le montant est déjà calculé d’après le pas ; il ne reste qu’à confirmer. Le minuteur du tour est repris dans la fenêtre, pour ne pas avoir à la fermer afin de vérifier l’heure.

Quand une offre est dépassée, le participant l’apprend aussitôt et en dépose une nouvelle depuis la même fenêtre. L’enchère automatique évite de rester devant l’écran : il suffit de fixer un plancher, et le système baisse le prix pas à pas. Le champ refuse un montant supérieur à l’offre en cours — et dit pourquoi.

Quand le fil s’allonge, le bloc du minuteur et des actions s’épingle en haut : l’enchère automatique se modifie ou s’annule sans remonter la page.

Le résultat. Une fois les enchères terminées, la même page devient le procès-verbal : l’offre gagnante, le gagnant, les coordonnées de l’organisateur, un contrat type et le procès-verbal des enchères à télécharger.

6. Les e‑mails font partie du parcours
Un appel d’offres dure des semaines, et l’utilisateur passe l’essentiel de ce temps hors du produit. Une matrice d’e‑mails pour les deux rôles a donc été conçue avec les écrans : invitation, rappel deux jours avant la clôture des candidatures, décision sur une candidature, enchères demain, résultat.
Système et handoff
Une bibliothèque de composants — typographie, boutons, champs, cartes, statuts — a été construite avant les écrans détaillés ; les nouvelles sections se sont assemblées à partir de l’existant.
Sept largeurs : 1920, 1600, 1440, 1280, 1024, 768 et mobile. Le responsive est dessiné pour chaque écran clé, enchères comprises.
Les sections sont marquées prêtes pour le développement au fur et à mesure : le développeur voit ce qu’il peut prendre et ce qui est encore en discussion.
Résultat
La plateforme est conçue de bout en bout : inscription et profil d’entreprise, création d’un appel d’offres, catalogue, page d’appel d’offres dans chaque rôle et chaque étape, candidatures, enchères avec enchère automatique, achats, calendrier, support et e‑mails.
Ce qui a été difficile
Une entité, plusieurs visages. Une page d’appel d’offres devient vite un empilement de « si le rôle est ceci et l’étape cela ». Un tableau d’états a tout sauvé : nous nous sommes d’abord mis d’accord sur le tableau, puis nous avons dessiné.
Les cas rares comptent plus que les cas fréquents. Un appel d’offres avec une seule candidature n’arrive pas souvent, mais c’est à ce moment que l’acheteur décide s’il fait confiance à la plateforme.
Captures issues des maquettes, sur des données de démonstration.