Le Centre de notifications assure une expédition de notifications unifiée et multicanale sur l'ensemble de la suite. Un simple appel émis par n'importe quel module se traduit par une distribution sur un ou plusieurs canaux : la boîte de réception intégrée, accessible via la cloche de notification dans la barre de navigation, l'e-mail HTML aux couleurs de la marque, les notifications push mobiles et les SMS. Le choix du canal n'est pas codé en dur par le module appelant ; il est décidé de manière centralisée, si bien qu'un même événement sous-jacent peut atteindre un destinataire sous forme d'une discrète entrée dans la boîte de réception et un autre sous forme de SMS, selon la politique et les préférences.

La distribution est résiliente par conception. Chaque notification est expédiée par canal avec un suivi de réussite indépendant : ainsi, une défaillance sur un transport, un e-mail rejeté ou un point de terminaison push injoignable, ne bloque jamais la distribution sur les autres, et chaque tentative est consignée. Les destinataires bénéficient d'une expérience cohérente quelle que soit la source : une boîte de réception homogène avec compteurs de non-lus, statuts lu et rejeté, regroupement par catégories et liens directs vers l'enregistrement à l'origine de l'alerte. Les synthèses regroupent les éléments de moindre priorité dans des récapitulatifs par e-mail programmés, de sorte que les personnes préférant un point périodique à un flot de messages individuels restent informées sans être interrompues. La gravité est un attribut de premier plan tout au long du parcours : information, succès, avertissement et erreur bénéficient chacun d'un traitement visuel et d'un code couleur propres sur l'ensemble des canaux.

Au cœur du Centre de notifications se trouvent trois notions qui, ensemble, transforment un événement système brut en un message qu'une personne va lire. La première est l'événement : un fait nommé survenu quelque part dans la suite, comme la réaffectation d'un ticket ou une facture arrivée en souffrance, porteur d'une charge utile rassemblant les faits pertinents à propos de cet incident. Les événements sont exprimés selon une convention de nommage à points toute simple, qui permet d'adresser des familles entières d'événements en une seule fois.

La deuxième est la règle, qui constitue la politique permanente de l'organisation pour une catégorie d'événements. Une règle guette un motif d'événements, désigne l'audience qui doit en être informée, choisit les canaux, définit une gravité et une catégorie de regroupement, et fournit la formulation. Comme les règles s'appuient sur des motifs plutôt que sur des noms d'événements uniques, une règle peut régir toute l'activité d'un module tandis qu'une autre cible un incident précis et unique, et les administrateurs les superposent pour exprimer exactement la couverture souhaitée.

La troisième est la notification elle-même : le message concret et personnalisé distribué à un destinataire unique, doté de son propre statut lu et rejeté et de son propre lien vers l'enregistrement d'origine. L'audience est résolue de manière relationnelle plutôt qu'au moyen de listes figées : une règle peut ainsi s'adresser à la personne ayant déclenché l'événement, au propriétaire de l'enregistrement concerné, à toutes les personnes détenant un rôle donné ou à un individu nommément désigné, et les destinataires appropriés sont recalculés à chaque déclenchement de l'événement. La formulation est produite à partir de modèles dans lesquels des variables sont renseignées depuis la charge utile de l'événement, de sorte que titres, corps de message et liens sont propres à l'instance plutôt que génériques. La configuration des règles est distincte des enregistrements transactionnels sur lesquels elles agissent, ce qui maintient la politique de notification stable et gouvernée de manière centrale, tandis que les données opérationnelles qu'elle surveille évoluent en permanence.

Le workflow quotidien débute lorsqu'un module émet un événement. Le Centre de notifications charge les règles actives, les confronte à l'événement selon leur motif et, pour chaque règle qui correspond, il résout l'audience, interpole les modèles avec la charge utile et expédie vers les canaux choisis. Cela se produit en arrière-plan des opérations courantes : un utilisateur qui approuve une demande ou clôture un ticket poursuit simplement sa tâche pendant que les personnes concernées sont informées automatiquement.

Le workflow du destinataire, c'est la boîte de réception et ses compléments. Les personnes trient la boîte de réception intégrée, filtrent par catégorie et par gravité, suivent les liens directs pour agir sur ce qu'elles voient, et marquent les éléments comme lus ou rejetés ; les compteurs de non-lus et la cloche de la barre de navigation maintiennent la vigilance à jour en temps réel. Celles qui préfèrent une vigilance groupée reçoivent plutôt des synthèses programmées, et les gravités critiques en termes de délai escaladent vers les notifications push et les SMS afin que rien d'urgent n'attende la prochaine connexion.

Le workflow administratif, c'est la gestion des règles. Les administrateurs créent, modifient, activent et désactivent les règles depuis une interface de gestion dédiée, définissent les motifs d'événements et les audiences, composent les modèles, et activent ou désactivent des règles sans toucher au code d'aucun module. Un simple commutateur d'état actif permet de faire taire instantanément une règle trop bruyante ou de préparer une nouvelle politique pour l'activer le moment venu, ce qui donne à l'organisation un contrôle direct et en libre-service sur l'ensemble de son comportement de notification.

La précision du Centre de notifications réside dans son routage et sa gestion des modèles. La correspondance de motifs s'appuie sur des noms d'événements à points comportant des segments génériques (wildcards) : une règle peut ainsi s'abonner à tous les événements produits par un module, à tous les événements d'un type donné à travers les modules, ou à un incident précis et unique, et cette correspondance est déterministe et inspectable. Cela donne aux administrateurs un contrôle fin de l'ampleur : une vigilance situationnelle large là où elle aide, un ciblage chirurgical là où le bruit doit être évité.

La résolution de l'audience est tout aussi réfléchie. Comme les destinataires sont dérivés de l'événement et de l'état actuel de l'organisation plutôt que de listes de diffusion statiques, les notifications atteignent toujours les bonnes personnes, même lorsque la propriété, les rôles et l'appartenance aux équipes évoluent, et il n'y a aucune liste obsolète à maintenir. L'interpolation des modèles lie la formulation du message à la charge utile, en insérant les valeurs nommées dans les titres, les corps de message et les liens de navigation, de sorte que chaque message soit concret et exploitable, avec un lien fonctionnel vers l'enregistrement exact concerné. La classification par gravité impose un traitement homogène de bout en bout, couleur, importance visuelle et escalade de canal, pour que le langage visuel de l'urgence soit uniforme dans la boîte de réception, l'e-mail, le push et le SMS. L'e-mail lui-même est rendu au moyen d'un modèle aux couleurs de la marque et sensible à la gravité, avec un en-tête aux styles de l'entreprise, et la distribution tient compte du mode afin que les messages se comportent correctement dans les environnements de développement, de certification et de production. Le suivi de distribution par canal et l'isolation indépendante des défaillances permettent à l'organisation de voir ce qui a été envoyé, à qui, sur quel canal et avec quel résultat, ce qui étaye à la fois la confiance opérationnelle et l'auditabilité.

Le Centre de notifications est délibérément transversal : il est le canal auquel tout autre module fait appel lorsqu'il a besoin de dire quelque chose à quelqu'un, ce qui signifie qu'il s'intègre à l'ensemble d'entre eux plutôt qu'à quelques-uns. Son couplage le plus étroit est avec le Flow Engine, où un nœud de notification dédié permet à toute étape d'un processus automatisé de déclencher un message intégré et un e-mail dans le cadre d'un workflow : ainsi, approbations, escalades et transferts s'annoncent d'eux-mêmes au fil de leur progression. Il se positionne aux côtés du bus d'événements de la plateforme, de sorte que le même événement opérationnel qui fait avancer un workflow peut simultanément déclencher des notifications fondées sur des règles, maintenant l'automatisation des processus et la vigilance humaine en parfaite synchronisation.

Concrètement, les tickets de service du Service Desk déclenchent des alertes d'affectation et de non-respect des délais, les modules Finance et Facturation font remonter les factures en souffrance et les cycles de paiement achevés, les Achats et la Gestion des stocks escaladent les demandes d'approbation et les exceptions de stock, et les changements liés aux RH et à l'Identité notifient les propriétaires et les rôles concernés. L'accès est régi par le modèle central de permissions de la suite : qui peut créer et administrer des règles de notification est ainsi contrôlé selon le même cadre de politique qui protège toutes les autres fonctions du système. Comme la distribution, l'image de marque et le suivi des lectures sont résolus une fois pour toutes ici, chaque module hérite d'une expérience de communication professionnelle et cohérente sans avoir à en réimplémenter la moindre partie.

Les AI Workers sont des participants de premier plan au sein du Centre de notifications, et non de simples destinataires passifs. Les collaborateurs interrogent leur historique de notifications de manière conversationnelle, en demandant à un AI Worker de résumer ce qu'ils ont manqué, de ne faire remonter que les avertissements et les erreurs d'un module donné, ou d'expliquer pourquoi une alerte particulière leur est parvenue, et le Worker lit la boîte de réception ainsi que les règles en vigueur pour répondre en langage clair. Les Workers agissent également : ils marquent des éléments comme traités, réacheminent un message vers le bon propriétaire, ou rédigent et expédient une notification pour le compte d'une personne via ce même expéditeur unifié, soumis aux mêmes permissions.

Comme chaque signal opérationnel transite par ce centre, les AI Workers l'utilisent comme poste d'observation pour la détection d'anomalies et d'exceptions : ils surveillent le flux à la recherche de motifs inhabituels, une soudaine grappe d'événements de gravité erreur, une règle qui se déclenche bien plus souvent que d'ordinaire, une approbation restée non lue au-delà de son échéance, et émettent une alerte réfléchie plutôt qu'une alerte brute de plus. Ils extraient des détails structurés des événements et des documents à l'origine d'une notification, si bien qu'une alerte concernant une facture en souffrance arrive déjà résumée avec les chiffres qui comptent. En aide à la décision, un Worker recommande les règles à ajuster lorsqu'une catégorie devient bruyante, et propose des audiences et des gravités pour de nouvelles politiques. Plus déterminant encore, un AI Worker fait office de nœud d'approbation ou de revue au sein des workflows : le Flow Engine notifie le Worker, le Worker évalue le cas au regard de la politique, puis approuve, rejette ou escalade, en consignant son raisonnement et en renvoyant la décision dans le processus. Le Centre de notifications devient ainsi à la fois le moyen par lequel le travail est annoncé et, le cas échéant, celui par lequel il est jugé.