Connector & API Management

La gestion des connecteurs et des API constitue le hub d'intégration de Nashua 360 : le plan de contrôle unique par lequel la suite dialogue avec chaque système qui l'entoure. Elle gère le cycle de vie complet d'une intégration, depuis les identifiants et les points de terminaison qui définissent une connexion, en passant par les règles de transformation qui réconcilient les données externes avec le modèle propre à la suite, jusqu'à la planification, la supervision et le traitement des erreurs qui assurent une circulation fiable des données. Là où les autres modules produisent et consomment des données métier, ce module régit la manière dont ces données franchissent la frontière entre Nashua 360 et le monde extérieur.

Il s'inscrit au sein de l'administration système comme la lisière de la suite tournée vers l'extérieur. Chaque point de contact externe y est enregistré, doté d'identifiants et observé : API REST, SOAP et GraphQL, serveurs Model Context Protocol, courrier entrant et sortant, plateformes de contenu, systèmes clients et d'identité, partenaires d'échange de données informatisées et canaux bancaires. En concentrant cette responsabilité en un seul endroit, le module offre aux administrateurs un inventaire complet et auditable de la surface d'intégration de l'organisation, plutôt qu'une dispersion de connexions point à point enfouies dans des fonctionnalités isolées.

Le rôle du module

Le module gère l'ensemble complet des connexions externes dont dépend une entreprise moderne. Il assure un contrôle du cycle de vie complet des connecteurs API couvrant REST, SOAP et GraphQL, chacun disposant de son propre schéma d'authentification, de ses points de terminaison de base, de ses en-têtes, de sa politique de nouvelle tentative et de ses limites de débit. Il configure les serveurs Model Context Protocol qui exposent des outils et des ressources à la couche d'IA de la suite, et il détient la configuration du courrier entrant et sortant, à la fois SMTP pour l'envoi et IMAP pour la récupération, qui achemine notifications, rapports et trafic de campagnes.

Au-delà des connecteurs individuels, il pilote le déplacement des données à grande échelle. Les pipelines ETL et ELT extraient les données des systèmes sources, appliquent des règles de transformation déclaratives et les chargent dans la suite, ou déposent d'abord les données brutes puis les transforment sur place lorsque le magasin cible se prête mieux à ce travail. Il assure l'échange de données informatisées avec les partenaires commerciaux, maintient des connecteurs vers les plateformes de contenu, notamment WordPress, Sitecore, Adobe AEM, Drupal et Umbraco, et intègre les systèmes clients et d'identité. La synchronisation planifiée, la détection des deltas, les files d'attente d'erreurs de type dead-letter et la relecture complètent le tableau, de sorte que les connexions ne sont pas seulement définies, mais exploitées de façon continue et observable.

Le domaine et le modèle de données

Au cœur du domaine se trouve la notion de connexion : une relation durable et nommée avec un système externe. Une connexion porte tout ce qui est nécessaire pour atteindre ce système et lui faire confiance, ses points de terminaison, ses éléments d'authentification et ses paramètres de comportement, conservés sous forme de configuration structurée et typés selon la nature du système représenté, qu'il s'agisse d'une API, d'une plateforme de contenu, d'un fournisseur d'identité, d'un serveur de messagerie ou d'un canal bancaire. Les secrets rattachés à une connexion sont conservés à l'écart de la configuration ordinaire et chiffrés au repos, afin que les identifiants ne voyagent jamais avec les champs descriptifs que les administrateurs modifient couramment.

Une connexion prend son sens grâce à un pipeline, la définition de la manière dont les données circulent : quelle ressource est lue ou écrite, dans quel sens, selon quelle planification et sous quel mappage. Un pipeline référence une ou plusieurs règles de transformation, la logique déclarative qui remodèle les enregistrements externes vers le vocabulaire propre à la suite et inversement, en résolvant les noms de champs, les formats, les listes de codes et les unités. Chaque exécution d'un pipeline produit un enregistrement d'exécution qui consigne ce qui a été tenté, ce qui a réussi et ce qui a échoué, et tout enregistrement qui ne peut être traité est mis de côté dans une file d'attente d'erreurs, son contexte complet étant préservé pour inspection, correction et relecture. Ensemble, ces concepts permettent à un administrateur de raisonner sur les intégrations en termes métier : ce qui est connecté, ce qui circule, comment cela est traduit et ce qui s'est passé lors de la dernière exécution.

Connector & APIManagementAPI connectorsMCP serversCMS platformsIdentity providersEmail serverEDI & banking
Connector & API Management is the single control plane through which Nashua 360 reaches every external system.

Principaux workflows

L'enregistrement d'une connexion constitue le premier workflow. Un administrateur sélectionne le type de système, fournit ses points de terminaison et ses identifiants, choisit un schéma d'authentification et valide la connexion au moyen d'un test en direct qui confirme l'accessibilité et l'autorisation avant que la connexion ne soit enregistrée. À partir de là, la construction d'un pipeline lie cette connexion à un déplacement de données concret : le choix de la ressource, du sens, du mappage et de la planification, puis une exécution à blanc sur un échantillon pour confirmer que la transformation produit la forme attendue.

Une fois en service, les pipelines s'exécutent selon leur planification ou à la demande. Chaque exécution est supervisée en temps réel, le débit, la latence et les taux de réussite étant affichés sur le hub. Lorsque des enregistrements échouent à la validation ou qu'un système en aval les rejette, ils s'accumulent dans la file d'attente d'erreurs, où un opérateur peut examiner la charge utile fautive, ajuster un mappage ou les données sources, et relire les enregistrements concernés sans réexécuter l'ensemble du lot. La rotation d'un identifiant, la révision d'une règle de transformation ou la mise en pause d'un flux partenaire sont autant d'opérations de premier ordre, et chacune d'elles est consignée afin que l'état de toute intégration à n'importe quel moment passé puisse être reconstitué.

Une profondeur fonctionnelle qui compte

La couverture d'authentification du module est délibérément large, car l'intégration échoue le plus souvent à la frontière de confiance. Il gère les clés d'API, les jetons bearer, les identifiants HTTP basic et l'ensemble complet des types d'autorisation OAuth 2.0, y compris les client credentials pour les appels de service à service et les flux de code d'autorisation pour l'accès délégué, avec renouvellement automatique des jetons et gestion de leur expiration. Pour la fédération d'identité, il configure SAML 2.0 avec les identifiants d'entité, les points de terminaison de connexion et de déconnexion unique, les formats d'identifiant de nom et les certificats de signature X.509 ; OpenID Connect et OAuth 2.0 générique avec discovery, portées et gestion des redirections ; et la liaison d'annuaire via LDAP et Active Directory avec les noms distinctifs de base, les filtres d'utilisateurs et de groupes et TLS. Le provisionnement à la volée et le rattachement de comptes traduisent une connexion fédérée en un utilisateur gouverné au sein de la suite, et la déconnexion fédérée clôt proprement la session auprès du fournisseur.

La profondeur du déplacement des données est tout aussi réfléchie. Les connecteurs de contenu parlent le contrat natif de chaque plateforme, l'API REST de WordPress, les services item et GraphQL de Sitecore, l'API de fragments de contenu d'Adobe AEM, JSON:API de Drupal et l'API de diffusion d'Umbraco, chacun avec son idiome d'authentification approprié. La connectivité bancaire couvre les canaux PSD2, EBICS et SWIFT, récupérant les relevés et pilotant l'analyse selon la norme CAMT.053 afin que le rapprochement en amont reçoive des transactions propres et structurées. L'échange de données informatisées applique des formats de documents standard et des enveloppes propres à chaque partenaire. Tout au long du processus, les règles de transformation imposent la coercition des types de données, la traduction des listes de codes, la normalisation des devises et des unités et la validation référentielle, et les contrôles de nouvelle tentative, de temporisation et de dead-letter garantissent qu'une panne transitoire se dégrade en douceur plutôt que de provoquer une perte de données.

Son intégration à la suite Nashua 360

La gestion des connecteurs et des API constitue la lisière de l'ensemble de la plateforme, et presque tous les autres modules atteignent le monde extérieur par son intermédiaire. Elle collabore au plus près avec l'administration système, dont elle fait partie, s'appuyant sur le modèle de rôles et de permissions de la suite afin que seuls les administrateurs autorisés puissent consulter ou modifier une connexion et ses secrets. Elle transmet les définitions de serveurs Model Context Protocol à la gestion de l'IA, qui régit la manière dont les AI Workers de la suite découvrent et utilisent les outils externes. Elle fournit à la gestion de contenu les connecteurs actifs qui publient vers les plateformes de contenu externes et en extraient des données, et elle livre des données de relevés structurées à la comptabilité et au contrôle de gestion, où l'analyseur CAMT.053 et les routines de rapprochement consomment les flux bancaires que ce module planifie.

Les intégrations clients et d'identité alimentent les couches CRM et d'accès de la suite, de sorte que contacts, comptes et utilisateurs authentifiés proviennent des systèmes de référence et restent en phase avec eux. La configuration du courrier soutient les services de notification et de reporting sur lesquels de nombreux modules s'appuient pour joindre les personnes. Parce que chaque connexion est enregistrée de façon centralisée, le reste de la suite consomme les intégrations par référence plutôt qu'en intégrant ses propres identifiants, ce qui maintient l'ensemble de la surface externe de l'organisation inventoriée, dotée de permissions et observable depuis un seul endroit.

Le fonctionnement des AI Workers en son sein

Les AI Workers sont des opérateurs de premier ordre au sein de ce module, et non de simples spectateurs. Un administrateur peut demander, en langage naturel, quels connecteurs ont échoué pendant la nuit, comment un pipeline particulier a évolué, ou quel flux partenaire est en retard, et le Worker répond directement à partir des enregistrements d'exécution et de l'état des files d'attente. Les Workers exécutent des actions dans le cadre des permissions qui leur sont accordées : déclencher une synchronisation, relire un lot d'enregistrements en échec après une correction de mappage, effectuer la rotation d'un identifiant selon une planification ou mettre en pause une connexion défaillante.

Ils surveillent en permanence les anomalies et les exceptions, signalant une hausse de la profondeur de la file d'attente d'erreurs, une chute soudaine du débit, un jeton d'authentification proche de l'expiration ou un partenaire dont la cadence de livraison a fléchi, et ils les remontent sous forme d'alertes avant qu'un humain ne s'en aperçoive. Lorsqu'une charge utile externe arrive sous une forme inhabituelle, un Worker en extrait et structure les champs et propose un mappage de transformation, transformant une tâche d'inspection en une simple revue. Les Workers offrent une aide à la décision en expliquant pourquoi des enregistrements ont été rejetés et en recommandant la modification de règle corrective. Là où la gouvernance l'exige, un Worker intervient comme nœud d'approbation ou de revue dans les workflows du module lui-même, validant une nouvelle connexion vers un système sensible ou une modification d'un pipeline de production avant qu'elle ne prenne effet, son jugement étant consigné dans la même piste d'audit que toute action humaine.