Cas d'usage : sourcing de lieux et de prestataires événementiels

Une agence organise des événements pour des entreprises : séminaires, conventions, soirées clients, lancements de produit. Pour chaque demande, le chef de projet doit trouver un lieu, puis un traiteur, un prestataire technique et parfois une animation ou un transport.

Ce cas d'usage montre comment l'agence fait ce travail dans Dokos :

1. Elle décrit chaque lieu dans une fiche Lieu.
2. Elle saisit la demande du client dans un Brief Evenement.
3. Deux rapports notent chaque lieu et chaque prestataire sur 100 pour chaque brief à venir.
4. Un tableau de bord Insights montre les recommandations de tous les briefs.
5. Le Wiki garde les règles de notation et les décisions de l'équipe.
6. Après l'événement, le brief garde le lieu, les prestataires retenus et la satisfaction du client. Ces données améliorent les notes des briefs suivants.

Tous les exemples de cette page existent sur le site de démonstration demo.dokos.cloud.

Vue d'ensemble

      
flowchart LR
    B[Brief Evenement\ncritères et besoins du client] --> S{Notation\nsur 100}
    L[Fiches Lieu\ncapacités, formats, tarifs] --> S
    P[Fournisseurs\npar groupe] --> S
    S --> R[Rapports\nMatching lieux par brief\nMatching prestataires par brief]
    S --> I[Tableau de bord Insights\ntous les briefs à venir]
    R --> C[Choix du chef de projet\noptions, proposition]
    I --> C
    C --> H[Brief réalisé\nlieu et prestataires retenus,\nsatisfaction]
    H -->|historique client et secteur| S
    W[(Wiki\nBase de connaissances)] -. règles et décisions .-> S

    

Prérequis

• Le rôle Gestionnaire du système pour créer les types de document.
• Le rôle Gestionnaire de script pour enregistrer un rapport de script non standard.
• Les scripts serveur activés sur le serveur. Sinon, un rapport de script non standard affiche l'erreur « Server Scripts Disabled ». Voir Rapport de type Script.
• L'application Insights pour le tableau de bord.
• L'application Frappe Wiki pour la base de connaissances.

1. La fiche Lieu

Une fiche Lieu décrit un lieu que l'agence peut proposer : un château, un hôtel, un rooftop, une péniche. Elle regroupe ce que le chef de projet vérifie avant de poser une option. Le nom de la fiche est le Nom du lieu. Sur le site de démonstration, le type de document est rattaché au module Achats, parce que le lieu est acheté à un fournisseur.

Le champ Statut donne la relation de l'agence avec le lieu :

La fiche a neuf onglets. La dernière colonne donne les champs que la notation lit.

La table Espaces utilise le type de document enfant Espace du Lieu. Chaque ligne décrit une salle : nom (obligatoire), type d'espace, surface, capacités par configuration (théâtre, banquet, cocktail…) et prix de location à la journée. Les rapports ne lisent pas cette table. Ils utilisent les capacités maximales de l'onglet Capacités & espaces. Le chef de projet lit la table pour choisir la salle.

2. Le Brief Evenement

Un Brief Evenement enregistre la demande d'un client : l'événement, les participants, les critères de lieu, le budget et les prestations à trouver. Les rapports comparent chaque brief à venir avec les lieux et les fournisseurs. Le nom suit la série BRIEF-.YYYY.-.#### (par exemple BRIEF-2026-0006). Sur le site de démonstration, le type de document est rattaché au module Ventes.

Le nom du type de document n'a pas d'accent. Dodock accepte seulement des lettres ASCII, des chiffres, des espaces, des tirets et des tirets bas dans le nom d'un type de document. Les étiquettes des champs peuvent avoir des accents.

Le brief a trois onglets :

Le Statut suit l'avancement : Nouveau, Recherche de lieu, Options posées, Proposition envoyée, Confirmé, puis Réalisé, Perdu ou Annulé.

• Les rapports notent les briefs dont le statut n'est pas Réalisé, Perdu ou Annulé et dont la date de début n'est pas passée.
• Un brief Réalisé devient de l'historique. Son lieu retenu, ses prestataires retenus et sa satisfaction alimentent les critères Historique, Relation client, Satisfaction et Expérience. Remplissez l'onglet Lieu & prestataires retenus avant de passer le brief à Réalisé.

3. Fournisseurs et clients

Les prestataires sont des Fournisseurs standard. Leur Groupe de fournisseurs donne leur catégorie. Sur le site de démonstration :

Les clients sont des Clients standard. Le secteur d'activité du brief vient du champ Secteur d'activité du brief, sinon du secteur du client. Les règles d'historique comparent ce secteur avec celui des briefs réalisés.

4. Les règles de notation

Les règles de cette section sont celles des rapports du site de démonstration. Elles sont un exemple. Adaptez les points à votre activité (voir la section 9).

Note d'un lieu sur 100

Chaque couple brief × lieu reçoit une note. Les comparaisons de texte ignorent les majuscules et les accents.

Les besoins spécifiques comptés dans le critère Besoins :

Coût estimé du lieu

Le coût estimé HT utilise la première règle qui s'applique :

1. Hébergement requis et tarif séminaire résidentiel renseigné : tarif résidentiel × participants × nombre de nuits (au moins 1).
2. Format horaire Demi-journée et tarif demi-journée renseigné : tarif demi-journée × participants.
3. Format horaire Soirée et tarif privatisation soirée renseigné : tarif privatisation soirée.
4. Séminaire, formation, conférence ou assemblée générale, avec un tarif journée d'étude : tarif journée d'étude × participants × nombre de jours.
5. Sinon, dans cet ordre : tarif privatisation jour, tarif privatisation soirée, tarif journée d'étude × participants.

La Part du budget est le coût estimé divisé par le budget total HT du brief. Ce coût sert à comparer les lieux. Il ne remplace pas le devis du lieu.

Niveau d'adéquation et critères bloquants

Capacité, format et localisation sont des critères bloquants. Si l'un d'eux vaut 0, le lieu est au mieux « 3 - À étudier », même avec une note de 75. Le chiffre devant le niveau permet de trier la colonne.

La colonne Points à vérifier liste les critères à contrôler avant de poser une option : Capacité (moins de 20 points), Format (0 point), Localisation (moins de 20 points), Budget (moins de 8 points), puis chaque besoin spécifique non satisfait.

Note d'un prestataire sur 100

Un fournisseur est candidat pour un brief dans deux cas :

• Il appartient au groupe d'une prestation cochée dans Prestations à sourcer, et il n'est pas désactivé.
• Il est lié à un lieu qui a au moins 65 points et aucun critère bloquant pour ce brief. C'est alors l'exploitant du lieu, son traiteur (si le brief demande un traiteur ou la restauration) ou son prestataire technique (si le brief demande la technique).

Le rapport affiche une ligne par brief × fournisseur, avec tous ses rôles.

Une mission est un brief réalisé où le fournisseur est l'exploitant du lieu retenu, le traiteur retenu ou le prestataire technique retenu. La satisfaction est celle de ces briefs. Les factures d'achat validées du fournisseur sont affichées dans Achats facturés HT. Elles ne changent pas la note.

5. Les rapports de matching

Les deux rapports sont des Rapports de Script non standard, écrits en Python. Leur Doctype de Réf. est Brief Evenement : un utilisateur qui peut lire les briefs peut ouvrir les rapports. Ils ont un filtre optionnel Brief. Sans filtre, ils montrent tous les briefs à venir. Les lignes sont triées par date, par brief, puis par note décroissante.

Le Python est préféré à une requête SQL pour trois raisons : chaque critère est une fonction courte, les pondérations sont des constantes nommées en tête du script, et un rapport peut réutiliser le calcul de l'autre. Le script n'a pas de fonction execute. Il se termine par data = colonnes, lignes. Voir Rapport de type Script pour créer ce type de rapport.

Matching lieux par brief

Une ligne par brief × lieu actif.

Exemple : pour la soirée de Banque Horizon (BRIEF-2026-0006, 250 personnes, Paris, standing Premium), l'Hôtel Belvédère Paris Étoile a 91,2 et le Domaine de la Clairière 86. Le Domaine est à Rambouillet : il reçoit 14 points de localisation, et « Localisation » apparaît dans ses points à vérifier.

Matching prestataires par brief

Une ligne par brief × fournisseur candidat.

6. Le classeur et le tableau de bord Insights

Les rapports répondent à la question « que proposer pour ce brief ? ». Le tableau de bord répond à la question « où en sont tous les briefs à venir ? ». Pour créer un classeur et un tableau de bord, voir Insights.

Le classeur Sourcing lieux & prestataires contient deux requêtes de base en SQL natif :

• Matching brief × lieu : une ligne par brief à venir × lieu actif, avec la même notation que le rapport des lieux.
• Matching brief × prestataire : une ligne par brief à venir × fournisseur candidat, avec la même notation que le rapport des prestataires.

Les règles sont donc écrites deux fois : en Python dans les rapports et en SQL dans le classeur. Une requête SQL d'Insights doit commencer par SELECT. Une requête qui commence par WITH est refusée. Placez-la dans un SELECT … FROM (WITH …).

Le tableau de bord Sourcing lieux & prestataires – briefs à venir affiche six graphiques :

Le tableau de bord n'a pas de filtre global par brief. Pour voir un brief, saisissez l'intitulé de l'événement dans la ligne de filtre sous l'en-tête evenement d'un tableau.

7. La base de connaissances dans le Wiki

Les règles de notation décident des lieux proposés aux clients. Toute l'équipe doit donc pouvoir les lire, pas seulement la personne qui maintient les rapports. L'agence les écrit dans Frappe Wiki, dans l'espace Base de connaissances, groupe Sourcing événementiel :

Le Wiki sert de référence commune :

• Un chef de projet comprend pourquoi un lieu est « À étudier » sans lire le code.
• La direction valide une pondération sur une page lisible, puis le responsable des rapports l'applique.
• Le Journal des décisions explique l'état actuel : par exemple, le nom sans accent du type de document, ou le passage des rapports de SQL à Python.
• L'assistant Dokos AI peut chercher dans le wiki interne. Il répond alors avec les règles de l'agence.

8. Construire la solution avec un assistant IA

Sur le site de démonstration, un assistant IA a créé cette solution. Il était connecté au site avec les permissions d'un utilisateur. Vous pouvez utiliser l'assistant intégré ou un assistant externe. L'assistant propose chaque création et vous la validez.

Procédez par étapes et vérifiez chaque résultat :

1. « Crée un type de document Lieu pour une agence événementielle B2B, avec des onglets Général, Localisation & accès, Capacités & espaces, Formats & équipements, Restauration, Tarifs & conditions, RSE, Évaluation & historique et Documents, et une table enfant des espaces. »
2. « Crée un type de document Brief Evenement : client, type d'événement, dates, participants, critères de lieu, budget, besoins spécifiques, prestations à sourcer, lieu et prestataires retenus, satisfaction. »
3. « Crée dix lieux, des fournisseurs par groupe et des briefs réalisés et à venir pour tester. »
4. « Crée un rapport de script en Python, Matching lieux par brief, qui note chaque lieu sur 100 pour chaque brief à venir avec ces règles : … » Collez les règles de la section 4.
5. « Crée le rapport Matching prestataires par brief à partir du même calcul. »
6. « Dans Insights, crée un classeur Sourcing lieux & prestataires avec ces deux calculs, et un tableau de bord des briefs à venir. »
7. « Crée dans le Wiki les pages de la base de connaissances Sourcing événementiel. »

Demandez un rapport de script en Python. Une requête SQL convient pour une liste simple. Pour une notation, le Python reste lisible et chaque règle est isolée. Utilisez SQL seulement si le Python ne peut pas produire le résultat.

Après chaque étape, ouvrez le document créé. Exécutez le rapport sur un brief connu et contrôlez une note à la main.

9. Modifier les pondérations

Les pondérations sont des constantes nommées en tête des fonctions du script, par exemple PTS_CAPACITE = 20 ou SEUIL_BON = 65. Les mêmes règles existent à quatre endroits. Modifiez-les ensemble :

1. Notez la nouvelle règle et sa raison dans la page Journal des décisions du Wiki.
2. Ouvrez le rapport Matching lieux par brief, changez la constante dans le champ Script, puis enregistrez.
3. Ouvrez le rapport Matching prestataires par brief. Il contient une copie du calcul des lieux. Faites la même modification, puis enregistrez.
4. Dans le classeur Insights, modifiez la requête concernée : Matching brief × lieu ou Matching brief × prestataire.
5. Exécutez le rapport et le tableau de bord sur le même brief. Vérifiez que les notes sont les mêmes.
6. Mettez à jour la page Règles de scoring des lieux ou Règles de scoring des prestataires du Wiki.

La somme des points maximaux des critères doit rester égale à 100. Si la note d'un critère change beaucoup, revoyez aussi les seuils d'adéquation.

Voir aussi

• Personnalisation des documents : créer un type de document.
• Rapport de type Script et Rapports SQL.
• Insights et Un tableau Insights partagé reste vide.
• Frappe Wiki.
• L'assistant Dokos AI.