Pilotage : centres de rôle et signaux de risque
Ce que l’écran donne à voir au quotidien : centres de rôle par métier, factbox, barre d’actions, les douze signaux de risque et leurs seuils, le rapport d’affaire, et le copilote qui lit le même refus structuré que le moteur.
Cette page décrit les écrans de pilotage qu’un utilisateur croise chaque jour, une fois les règles et les packs en place : l’accueil qui se recompose par rôle, le résumé contextuel d’une fiche, la liste de priorités qui pousse vers l’action, les indicateurs de risque avec leur preuve documentaire, le rapport d’affaire qui agrège devis-achats-production, et le copilote qui explique un refus dans la langue de l’utilisateur.
Centres de rôle
Un accueil par rôle
L’accueil peut basculer d’un tableau de bord générique à un centre de rôle : sept rôles — acheteur, chef d’atelier, comptable, commercial, RH, qualité, direction — chacun avec ses propres tuiles de KPI et ses files (demandes d’achat à traiter, réceptions à contrôler, factures à envoyer…). La bascule se mémorise par navigateur (avia-role-center en local storage) ; changer de rôle redessine les tuiles sans quitter la page.

Centre de rôle, rôle Acheteur : demandes d’achat, PO à envoyer, réceptions, factures, fournisseurs à risque.

La bascule et le changement de rôle redessinent les tuiles sur place, sans quitter la page.

Rôle Comptable : les tuiles changent (factures échues, périodes à clôturer) ; le centre d’actions reste le même panneau.

Rôle Chef d’atelier : des files de production (OF, postes, NC) à la place des tuiles achats ou finance.
Le résumé contextuel (factbox)
Le panneau qui suit la sélection
Un factbox est un panneau latéral qui suit la fiche courante sans navigation complète : le même panneau Flux du document décrit sur la page d’ensemble apparaît en aperçu sur les listes de factures, de fournisseurs et de commandes d’achat quand une ligne est sélectionnée, et une fiche fournisseur ou article porte son propre résumé (identité, classification, activité) plus le bandeau de risque quand des signaux dépassent leur seuil — visible ci-dessous sur la fiche fournisseur.

Factbox résumé (à droite) et bandeau de risque (en haut) : le même signal lu de deux façons sur la même fiche.

Cocher une ligne ouvre le factbox ; cocher une deuxième ligne fait aussi apparaître la barre d’actions groupées (archiver, supprimer).

Le même factbox sur un OF : quantité, opérations, et — une fois terminé — son lot de traçabilité et sa quantité.
Centre d’actions
La liste qui pousse vers l’action
À côté des tuiles de rôle, le centre d’actions (visible à droite de la capture ci-dessus) classe ce qui réclame une décision maintenant — les éléments qui requièrent attention d’abord, puis le reste de la file — plutôt qu’une liste plate de KPI. Il se lit comme une estimation sur échantillon, pas encore un agrégat API (le portail le dit explicitement, roleCenter.approximateHint), et chaque ligne renvoie directement à la fiche.

Le même centre d’actions sur le tableau de bord classique (centre de rôle désactivé) : requiert attention, détections IA, tâches suggérées.
Signaux de risque
Douze indicateurs, des seuils paramétrables
Un moteur dédié (internal/risk) calcule douze indicateurs — fiabilité fournisseur, délai article, disponibilité et pannes de poste, retards transporteur — chacun sur une fenêtre par défaut de 90 jours, paramétrable. Les seuils ne sont pas des constantes : le type de règle seuil_risque les paramètre par indicateur (attention, critique, fenetre_jours, echantillon_min), en portée locataire, fournisseur, article ou poste. Sans règle paramétrée, des seuils par défaut s’appliquent.
| Indicateur | Entité | Signifie |
|---|---|---|
supplier.otd | Fournisseur | réceptions à l’heure / réceptions totales |
supplier.retard_moyen_j | Fournisseur | retard moyen des réceptions en retard, en jours |
supplier.taux_nc | Fournisseur | non-conformités / réceptions |
supplier.note | Fournisseur | dernière note d’évaluation et son ancienneté |
article.delai_reel_vs_annonce | Article | écart entre délai réel et délai annoncé |
workstation.couverture_qualif | Poste | part des opérateurs affectés qualifiés au niveau requis |
employee.qualif_poste | Employé × poste | affecté, niveau requis, certification à jour ? |
workstation.pannes_90j | Poste | nombre de pannes sur la fenêtre |
workstation.mtbf_h | Poste | temps moyen entre pannes, en heures |
workstation.disponibilite | Poste | disponibilité moyenne du poste sur la fenêtre |
carrier.retard | Transporteur | part des livraisons en retard |
article.taux_nc | Article | non-conformités / ordres de fabrication terminés |
Chaque signal rend { code, valeur, unite, fenetre_j, n_echantillon, preuve[] } — la preuve est constituée de 3 à 5 documents à l’appui, jamais un simple score. Sur le flow-designer, le même moteur évalue un flux entier d’un coup et classe les problèmes les plus probables, critique d’abord — la capture ci-dessous montre trois signaux critiques remontés sur un flux nommé d’après le risque qu’il illustre.

Simulation sur le flux « SEED-FLOW-Risque critique » : coût et délai estimés, puis les problèmes probables, critique d’abord.
Rapport d’affaire
Chiffres, jalons, documents, risques
Le rapport d’affaire agrège les chiffres d’une affaire sur un seul écran : budget, chiffré (depuis le devis), engagé (commandes d’achat), réalisé, coût prévisionnel et marge réelle ; ses jalons ; un décompte des documents (devis, commandes d’achat, ordres de fabrication, bons de livraison) avec la même chaîne de flux du document décrite sur la page d’ensemble ; et les problèmes probables du moteur de risque, spécifiques à cette affaire (GET /api/v1/risks/affair/{id}).

Rapport d’affaire : chiffres, jalons, documents et flux du document, risques probables — un écran par affaire.
C’est exactement l’écran que prépare le pack Contrôle de gestion : la dimension AFFAIRE exigée sur facture alimente les chiffres « engagé / réalisé » montrés ici — voir l’exemple contrôle de gestion.
Le copilote
Le même refus, expliqué
Le rail du copilote (visible sur le bord droit de chaque capture de cette page) lit le même refus structuré ({ code, params, message }) qu’une règle produit, pour l’expliquer en langage courant et guider l’utilisateur vers la correction — changer la quantité reçue, choisir une autre période, demander une approbation. Le prompt le restreint à uniquement le contexte fourni : le copilote explique, il ne calcule pas ses propres chiffres.
Sur le flow-designer et sur une page d’affaire, la même liste d’alertes que calcule le moteur de risque est injectée dans le contexte du copilote — le même JSON que celui affiché par le panneau, rien de recalculé côté IA. Lui demander « pourquoi ce nœud est rouge » et il lit l’indicateur, le seuil franchi, et les documents à l’appui déjà renvoyés par le moteur.
GET /api/v1/ai/explain-refusal
{
"code": "habilitation_requise",
"params": { "operateur": "Amine T.", "poste": "Sertissage 3", "niveau_requis": 2 },
"message": "L’opérateur Amine T. n’est pas habilité au niveau requis (niveau 2) pour le poste Sertissage 3."
}← Retour à Règles métier et contrôle
Voir aussi : Catalogue des types · Packs par métier · Mise en service · Exemples par secteur · Copilote · Profils de statuts







