ADV-03 — Alertes expiration BDC J-15

Fonction	Nature	Framework	Score	Statut
ADV	Automatisation	n8n	19	🟢 En développement

Source : atelier ADV 29/07/2026 — synthèse mentionne “suivi manuel via Excel, cible extraction depuis Projet CI (Progessi) pour alertes automatisées”.

Contexte métier (extrait transcript)

Deux fichiers Excel personnels (un par ADV, contenus différents) — Bahija/Vanessa : “Chacune a le mien, c’est différent”, alimenté manuellement à chaque nouveau contrat.
Vanessa décrit le fichier : “On a le nom du client, le nom du collaborateur, et on a les dates de début et date de fin de contrat directement sur le tableau. C’est la seule manière qu’on a pour suivre les contrats.”
Constat Progessi cité en séance : “Sur le projet-CI, on met les dates de fin de contrat, mais on n’a pas d’alerte.” → la donnée existe côté Progessi (projects.endDate), l’absence d’alerte proactive est le vrai gap.
Enjeu commercial (Bahija) : “Ça permettrait de prévenir les commerciaux, d’anticiper et prévenir les commerciaux en amont pour qu’on ne soit pas embêté lors de la facturation, qu’on ne soit pas sans bons de commande.”
Enjeu quotas jours prestés (Vanessa) : “On a des nombres de jours pas mal dépassés sur l’année pour certains clients, et ça permet justement de ne pas… je fais des points au trimestre à peu près avec les commerciaux pour savoir si on est bien dans le quota.” Sans anticipation → “on se retrouve pas en fin de mois de décembre à poser des congés, obligée de demander au collab de déposer des congés pour respecter le nombre de jours.”
Progessi a récemment évolué : Bahija découvre en séance des tableaux natifs, graphes et exports CSV en page d’accueil. Gabriel : “Projet-C, ils ont vachement développé des choses cette année. […] Les graphes de visualisation, ils datent de deux mois peut-être.” → doublonner Progessi serait un anti-pattern. Formation ADV en parallèle recommandée.
Positionnement Mekorai : ce que Progessi ne fait pas nativement = l’ALERTE PROACTIVE avec jointure conso / échéance. C’est le périmètre n8n.
Rupture BDC = rupture facturation = mission en danger.

Transcripts sources : ADV atelier 29/07/2026 (synthèse + verbatim), restitution consolidée DG vagues 1-2, cadrage ateliers Discover 28-29 juillet.

Objectif du cas d’usage

Interroger chaque matin la ressource projects de Progessi via POST /projects (search avancée FilterModel sur endDate ≤ D+15 et statut actif), calculer la consommation en jours prestés depuis timeEntries validés, et pousser une alerte structurée au responsable ADV compétent (Bahija Paris ; Vanessa Aix + BU restantes ; ADV Rouen/Lyon selon périmètre). Escalade commercial mission si endDate ≤ D+5 ou dépassement quota. La donnée BDC (dates fin, quota) EST déjà dans Progessi — Mekorai ajoute UNIQUEMENT l’alerte proactive et la jointure conso ↔ échéance. Digest hebdo lundi matin. Aucun endpoint d’écriture Progessi utilisé : pas de renouvellement automatisé, pas de création de facture, pas de fermeture de projet.

Étapes fonctionnelles détaillées

Chaque matin à 8h00 : interroger Progessi pour lister tous les BDC actifs et leurs dates d’expiration.
Filtrer ceux expirant dans ≤ 15 jours.
Pour chacun, calculer la consommation (jours prestés via timeEntries validés) vs quota autorisé.
Détecter les cas critiques :
- Expiration ≤ 5 jours (urgent)
- Consommation > quota autorisé (dépassement)
Envoyer un mail au responsable ADV (Bahija ou Vanessa selon périmètre) avec le détail.
Escalader au commercial mission si ≤ 5 jours et pas d’action à J-1.
Chaque lundi 9h00 : envoyer un digest hebdo consolidé à toute l’équipe ADV.

Flot d’appels API

flowchart TD
    Cron1[Cron n8n 8h00 tous les jours] --> Projects[Progessi<br/>POST /projects<br/>FilterModel statusCode=ACTIVE<br/>+ endDate lte today+15]
    Projects --> Loop[Pour chaque projet]
    Loop --> Customer[Progessi<br/>GET /customers/customerId<br/>nom client + code]
    Loop --> Conso[Progessi<br/>POST /timeEntries<br/>FilterModel projectId=X<br/>+ statusCode=VALIDATED<br/>somme nbDays]
    Loop --> Consultant[Progessi<br/>GET /profiles/consultantId]
    Customer --> Merge[Merger contexte<br/>client, mission, consultant]
    Conso --> Merge
    Consultant --> Merge
    Merge --> Calc[Calculer<br/>jours restants,<br/>ratio conso/quota]
    Calc --> Level{Criticite ?}
    Level -->|conso gt 100 quota| Depass[Tag DEPASSEMENT]
    Level -->|endDate lte 5j| Urgent[Tag URGENT]
    Level -->|endDate 6-15j| Alert[Tag ALERTE]
    Depass --> Map[SQLite n8n<br/>projet_adv_owner<br/>+ commercialId Progessi]
    Urgent --> Map
    Alert --> Map
    Map --> MailADV[Graph<br/>POST /me/sendMail<br/>vers responsable ADV BU]
    Map --> MailCom[Graph<br/>POST /me/sendMail<br/>vers commercial mission<br/>si Urgent ou Depass]
    MailADV --> Log[(SQLite n8n<br/>bdc_alerte_log)]
    MailCom --> Log

    Cron2[Cron n8n lundi 9h00] -.-> Digest[Digest hebdo consolide<br/>tous BDC critiques semaine]
    Digest -.-> MailAllADV[Graph<br/>POST /me/sendMail<br/>vers equipe ADV]

Confrontation à l’API Progessi réelle

Vérification faite contre la spec OpenAPI progessi-read-api.json (reçue 2026-08-25). Mode READ-only, BasicAuth. Point crucial : la spec expose 20 resources, mais PAS de resource salesOrders ni purchaseOrders — les BDC vivent dans projects (mission = “Projet CI” dans le jargon Proxiad).

Besoin fonctionnel	Endpoint Progessi	Disponible ?	Commentaire
Lister BDC / missions actifs	`POST /projects` FilterModel `statusCode=ACTIVE`	✅	Resource `projects` = équivalent BDC/mission. Pas de resource `salesOrders` dans la spec.
Récupérer date fin BDC	Champ `endDate` sur `projects`	✅	Confirmé en séance : “On met les dates de fin de contrat sur Projet-CI”
Filtrer BDC expirant ≤ 15 j	FilterModel `endDate LTE today+15`	✅	Filtre standard OpenAPI
Récupérer conso jours prestés	`POST /timeEntries` FilterModel `projectId=X` + `statusCode=VALIDATED`	✅	28 champs sur `timeEntries` — sommer `nbDays` sur périmètre BDC
Récupérer quota jours BDC	Champ `quotaDays` (ou équivalent) sur `projects`	❓ À qualifier	Non explicitement listé — fallback = calcul à partir de `budgetAmount / tjm` si les champs existent
Récupérer client de la mission	`GET /customers/{customerId}` via lien `projects.customerId`	✅	Utile pour intitulé mail
Récupérer commercial de la mission	Champ `commercialId` (ou `ownerId`) sur `projects`	❓ À qualifier	Confirmer nommage exact via `GET /projects/{id}` sur mission test
Mapping BDC → responsable ADV (Bahija/Vanessa/autres BU)	—	❌ (côté Progessi)	Règle interne Proxiad, à stocker dans SQLite n8n `projet_adv_owner`
Créer une tâche/alerte DANS Progessi	`bpmTasks`	❌ en écriture	Resource `bpmTasks` accessible en READ uniquement — impossible de créer une notification native Progessi
Renouveler / prolonger un BDC	—	❌	Aucune écriture — action manuelle commercial obligatoire
Créer facture prorata / avenant	—	❌	Aucune écriture sur `salesInvoices` (58 champs lisibles seulement)
Statut e-invoice si facturation en cours	Champs `electronicInvoiceStatusCode`, `eReportingStatusCode`, `dunningLevel` sur `salesInvoices`	✅	Non utilisé v1, mais réservoir pour v2 (croiser BDC / statut Chorus Pro)

Bloquants API :

Pas de resource dédiée salesOrders — le BDC est modélisé comme un project. Nommage à confirmer avec Progessi (est-ce que 1 BDC = 1 project, ou 1 project peut recouvrir plusieurs BDC successifs ?).
Champ quotaDays non confirmé — impossible aujourd’hui de garantir le calcul de dépassement quota sans qualification 30 min.
Champ commercialId sur projects non confirmé — nommage exact à vérifier.
Pas d’écriture Progessi → impossible de créer une tâche BPM alertant nativement Bahija dans Progessi ; le mail Graph est le seul canal.

Contournements retenus :

Table projet_adv_owner (project_id, adv_owner_email, adv_owner_name) alimentée par règle métier ADV — permet le routage Bahija Paris vs Vanessa Aix vs autres BU (Rouen, Lyon Easton) indépendamment de Progessi.
Table bdc_alerte_log (project_id, alert_level, sent_at, recipient, action_taken) pour anti-doublon (ne pas relancer 2× sur le même BDC dans la même semaine).
Si quotaDays absent : calcul de secours = budgetAmount / tjm_moyen (à valider commercial) ; sinon dégradé sur alerte pure endDate.
Formation Progessi ADV en parallèle (Bahija/Vanessa) sur les graphes natifs Projet-CI récents — Mekorai ne remplace pas Progessi, il complète l’alerte proactive.

API map — fonctions requises

#	Étape	Fonction / endpoint	Application	Existe ?	Accès dispo ?	Notes
1	Lister BDC actifs	`POST /salesOrders` search FilterModel `status=active`	Progessi	❓ À qualifier	✅	Investiguer : entité `salesOrders` ? champ sur `projects` ? Session partage écran 30 min Bahija
2	Récupérer expirations	Champ `endDate` sur BDC	Progessi	❓	✅	Même investigation
3	Récupérer quotas	Champ `quotaJours` ou similaire	Progessi	❓	✅	Même investigation
4	Récupérer conso	`GET /timeEntries?bdcId=X&status=validated`	Progessi	✅	✅	Filtrer sur CRA validés uniquement
5	Mapping BDC → responsable ADV	Table locale ou champ Progessi	Progessi ou n8n	❓	—	À qualifier
6	Mapping BDC → commercial	Champ `commercialId` sur BDC	Progessi	❓	✅	Investigation
7	Envoyer mail	`POST /me/sendMail`	Microsoft Graph	✅	⚠️ Extension droits	Idem ADV-01

Prérequis techniques

Compte service Progessi (confirmé)
Profils M365 étendus MekorAI
Session de qualification 30 min avec Bahija pour cartographier structure BDC dans Progessi

Livrables Proxiad attendus

Cartographie BDC dans Progessi — session partage écran Bahija (30 min)
Mapping BDC → responsable ADV (Bahija vs Vanessa selon règle client/périmètre)
Mapping BDC → commercial mission (pour escalade)
Source conso jours : timesheets validés ou compteur natif Progessi ?
Seuils (15 j confirmé ? 5 j escalade confirmé ? +0/+5/+10% dépassement ?)
Templates mails (alerte / urgence / dépassement)
Planification formation ADV sur fonctionnalités BDC natives Progessi (quick win parallèle)

Timeline estimative

Effort dev : 2 jours-n8n.

Jalons :

S+0 : session cartographie BDC Progessi (30 min)
S+1 J1 : workflow détection + conso + mails
S+1 J2 : tests + démo
S+2 : mise en production

Critères de recette

Alerte quotidienne pour chaque BDC ≤ 15 j
Alerte contient : client, mission, consultant, expiration, quota/conso, lien Progessi
Digest hebdo lundi matin
Escalade commercial à J-5
Dépassement quota (>100%) alerte immédiate
Zéro faux positif sur 1 mois (BDC renouvelés n’apparaissent plus)

Risques identifiés

Risque	Impact	Mitigation
Structure BDC pas claire dans Progessi	Blocage	Session qualification préalable OBLIGATOIRE
Conso calculée sur CRA non validés	Alertes faussées	Utiliser uniquement CRA validés
Doublon avec fonctionnalité native Progessi	Redondance	Formation ADV parallèle : Mekorai fait ce que Progessi NE FAIT PAS (alerte proactive + jointure conso)
BDC sans commercial attribué	Escalade impossible	Fallback : mail à ADV avec tag “commercial à attribuer”

Questions ouvertes

Q1 : Où vivent les BDC dans Progessi ? Entité dédiée salesOrders / purchaseOrders ? Champ sur projects ? Champ sur salesInvoices ?
Q2 : Le champ commercialId existe-t-il pour l’escalade ?
Q3 : Quota jours — champ natif Progessi ou à calculer à partir du montant BDC / TJM ?
Q4 : Formation Progessi ADV — quand ? Qui la donne (Progessi éditeur ? Nous ?) — plutôt en amont ou parallèle ?
Q5 : Seuil dépassement — 0% strict ou tolérance (+5% ? +10%) selon type BDC ?