Automatisations et surveillance

Les automatisations constituent la couche d’intégration d’Aptli : c’est la manière dont votre déploiement réagit à ce qui se passe en son sein et se connecte aux systèmes extérieurs. Elles couvrent quatre aspects : les règles qui déclenchent des actions lorsque des événements se produisent, les hooks qui transmettent des événements à d’autres systèmes, l’ingestion qui récupère les données des capteurs et des appareils, et la surveillance qui transforme ces données entrantes en mesures, graphiques et alarmes.

La fonctionnalité « Automations » est incluse dans toutes les formules. Ce qui est facturé, c’est le nombre de connexions externes que vous configurez — voir Le quota de connexions ci-dessous.

Aperçu des pages

La fonctionnalité « Automations » dispose de son propre groupe de navigation comprenant quatre pages :

Hooks — le moyen rapide de diffuser des événements

Un hook est une destination signée abonnée aux événements que vous sélectionnez. C’est l’intégration sortante la plus simple : attribuez-lui un Nom, une URL de destination, les Événements à envoyer, un Secret de signature (pour que le destinataire puisse vérifier que la charge utile provient bien de vous) et, en option, un Modèle de charge utile. Chaque événement correspondant est envoyé via une requête POST à cette URL. Pas de conditions, pas de branchement ; simplement « envoyer ces événements là-bas ».

Utilisez un hook lorsqu’un autre système a simplement besoin de savoir qu’un événement s’est produit. Optez pour un déclencheur d’événement (ci-dessous) lorsque vous avez besoin de conditions ou d’une action autre qu’un webhook.

Déclencheurs d’événements — des règles qui déclenchent une action

Un déclencheur d’événement est un moteur complet de type déclencheur → conditions → actions. Lorsqu’un événement se produit et que les conditions sont remplies, une ou plusieurs actions s’exécutent. Créez-en un nouveau à partir de la galerie de recettes « Que devrait-il se passer automatiquement ? », ou accédez directement à l’éditeur complet.

Déclencheurs

Les déclencheurs sont regroupés en fonction de la partie d’Aptli dont ils proviennent. En voici une sélection :

• Travail — workOrder.created, workOrder.statusChanged, report.completed, report.validated, report.rejected, validation.statusChanged
• Projets et tâches — project.created, project.statusChanged, job.created, job.removed
• Inventaire — inventory.created, stock.adjusted, stock.transferred, stock.low
• Importations et versions — geo.import.completed, geo.import.failed, version.submittedForReview, version.committed
• Utilisateurs, fichiers, demandes d’aide — user.invited, file.uploaded, file.quarantine_failed, helpRequest.created, helpRequest.statusChanged
• Données des capteurs — sensor.reading (se déclenche une fois par lot d’ingestion, en transmettant les agrégats de ce lot — le pont entre l’ingestion et l’automatisation)
• Alarmes — alarm.raised et alarm.resolved (§293). Contrairement à sensor.reading, celles-ci véhiculent la palette complète d’actions ; ainsi, une violation peut créer un ordre de travail, mettre à jour un champ ou notifier quelqu’un — et pas seulement déclencher un hook
• Planifiés — schedule.daily, schedule.weekly, schedule.monthly
• Minuteries SLA — timer.threshold, timer.expired, timer.escalated (émises par l’exécution de minuteries de cycle de vie)

Conditions

Les conditions déterminent quand un déclencheur se déclenche ; elles sont évaluées par rapport au contexte de l’événement et combinées par un opérateur « ET » (toutes doivent être satisfaites) :

• workOrder.status == 'completed' — uniquement à la fin de l’opération
• actor.email endsWith '@myorg.com' — uniquement les utilisateurs internes
• job.featureCount > 1000 — uniquement pour les importations volumineuses

Actions

Chaque déclencheur dispose d’un panneau Test intégré — un bouton qui applique la règle à un contexte d’échantillon synthétisé pour son déclencheur. Deux points à savoir avant de l’utiliser : il ignore les conditions (il exécute directement les actions), et il ne s’agit pas d’un test à blanc — les actions sortantes (webhook, Postgres, livraison d’artefacts) s’exécutent réellement vers les destinations que vous avez configurées, mais sont simplement signalées par un badge « test » dans la section « Livraisons ». Les e-mails sont vérifiés mais ne sont pas envoyés, et les actions modifiant les enregistrements (création/mise à jour) sont ignorées. Veillez donc à diriger votre test vers une destination sûre ; il sert à confirmer le câblage, et non à fournir un aperçu sans effet.

Ingestion — importation des données des capteurs et des appareils

Un connecteur d’ingestion est une source de données externe qui alimente Aptli en relevés. Chaque connecteur dispose d’un mode :

• Pull (interrogation planifiée) — Aptli interroge l’API REST d’un fournisseur à un intervalle (30 secondes minimum). Vous définissez l’URL, des identifiants et un petit mappage de réponse (chemin des mesures, clé d’horodatage, clé de valeur, clé de métrique) afin qu’Aptli puisse lire le JSON du fournisseur.
• Push (envois par l’expéditeur) — l’expéditeur envoie des lots JSON via une requête POST vers le point de terminaison entrant propre au connecteur (affiché une fois le connecteur enregistré), en s’authentifiant avec une clé API d’ingestion. Aucune interrogation n’est nécessaire ; l’appareil ou la passerelle envoie les données selon son propre calendrier.

Dans les deux cas, chaque connecteur spécifie un ID de fonction de station (la fonction de carte à laquelle appartiennent les relevés — voir Surveillance et alarmes) et une Unité, et chaque lot ingéré déclenche le déclencheur sensor.reading. L’onglet Ingestion affiche également un aperçu en temps réel des interrogations planifiées (nombre de celles qui sont actives, en retard ou ayant échoué).

Identifiants, clés et quota de connexion

Identifiants sortants

Les actions sortantes qui atteignent un système externe (webhooks, Postgres, livraison d’artefacts S3/SFTP) s’authentifient via un identifiant enregistré plutôt que par des secrets intégrés. Créez-en une une seule fois sur la page Identifiants et référencez-la par son nom. Les secrets sont chiffrés au repos et ne s’affichent plus jamais après leur enregistrement ; la configuration non secrète (URL de base, noms d’hôtes, régions) reste lisible. Types : bearer / basic / clé API pour HTTP, S3, SFTP et Postgres.

Clés d’ingestion entrantes

Clés « bearer » de machine permettant à un expéditeur d’envoyer des données vers Aptli. Elles sont réservées à l’ingestion uniquement, avec un périmètre limité à ce qu’elles sont autorisées à faire (envoyer des relevés ou récupérer des soumissions du portail), et la clé brute est affichée une seule fois lors de sa création — copiez-la à ce moment-là.

Le quota de connexions

Le compteur commercial correspond au nombre de connexions externes, et non à la fonctionnalité elle-même. Chaque connecteur d’ingestion, clé API et hook sortant réutilisable consomme une unité provenant d’un pool partagé (les règles internes de déclenchement d’événements ne sont pas comptabilisées). Un compteur sur les pages « Automations » et « Identifiants » affiche « {utilisés} sur {total} connecteurs/clés » avec une ventilation entre connecteurs, clés API et hooks. Le quota par défaut est de 3 ; lorsque vous l’atteignez, la création d’un nouvel élément vous invite à révoquer un élément inutilisé ou à contacter l’assistance pour en ajouter d’autres. Les connexions que vous possédez déjà continuent de fonctionner si le quota venait à diminuer par la suite.

Surveillance et alarmes

L’ingestion permet de recevoir les données des capteurs ; la surveillance correspond à ce que vous voyez et ce qui vous alerte.

Stations et relevés

Une station est simplement un élément cartographique sur lequel un capteur effectue ses relevés. Par défaut, l’ID de l’élément « Station » d’un connecteur correspond à l’identifiant propre à cet élément ; les relevés y sont donc directement associés. Les émetteurs utilisant leurs propres codes de station peuvent être liés explicitement.

Une fois que les relevés sont transmis, l’enregistrement de l’élément s’enrichit d’une section « Relevés du capteur » : pour chaque indicateur, la dernière valeur et son unité, ainsi qu’un graphique sparkline sur 7 jours. Si une station cesse d’émettre mais que sa source continue d’envoyer des données sous d’autres identifiants (un capteur a été renommé à la source), Aptli le signale et propose une option « Relier à nouveau » en un clic afin que vous ne perdiez pas l’historique.

Alarmes

Les règles d’alarme sont définies au niveau du connecteur d’ingestion. Activez Déclencher des alarmes et configurez :

• Déclencher une alarme lorsque la valeur est — supérieure ou inférieure à un seuil
• Marge de désactivation — de combien la valeur doit s’écarter du seuil pour que l’alarme se désactive automatiquement (hystérésis, afin qu’une valeur oscillant autour du seuil ne déclenche pas d’alarme à chaque fluctuation)
• Désactiver l’alarme après (minutes) — déclencher une alarme de silence si aucune donnée n’arrive pendant cette durée (détection de capteur hors service)
• Destinataires de l’alarme — qui est averti
• Escalade si non acquittée après (minutes) + Destinataires de l’escalade — un deuxième niveau d’alerte si personne n’acquitte à temps

La page Alarmes est le registre en temps réel. Chaque alarme est Active, Accréditée ou Résolue ; vous l’Accréditez pour signaler qu’une personne s’en occupe et vous la Résolvez lorsqu’elle est traitée (les alarmes s’effacent également automatiquement lorsque la mesure revient au-dessus de la marge de sécurité). Les alarmes de seuil et les alarmes de silence (« aucune donnée reçue ») sont affichées distinctement, et chaque alarme indique sa valeur/son seuil/son pic, la personne qui l’a acquittée et — si elle a été escaladée — une ligne «Escaladé {date} » accompagnée d’un badge indiquant l’état de livraison. Une carte du tableau de bord d’accueil met en avant les alarmes actives afin qu’elles ne passent pas inaperçues. La page Alarmes est visible par tout superviseur connecté, et pas seulement par les administrateurs des automatisations, ce qui permet aux personnes chargées de superviser le travail de suivre les alarmes.

Boucle bidirectionnelle des tickets

Un hook peut comporter une URL de retour avec chaque alarme : votre système de tickets externe envoie (POST) les changements de statut pour accuser réception ou résoudre l’alarme, et la référence du ticket s’affiche sur l’alarme sous forme de lien. Cela permet de boucler la boucle lorsque les alarmes sont traitées dans un autre outil.

Résultats et liens de partage

Dans un projet, l’onglet Résultats présente sous forme de graphiques les séries de métriques surveillées par rapport aux jalons de travail achevé — voir Projets. Vous pouvez publier un lien de partage en lecture seule et tokenisé de ces graphiques à l’intention de personnes externes, et le révoquer à tout moment. Les relevés sont affichés à titre contextuel aux côtés des dates de travail ; Aptli n’établit aucun lien de causalité et la page ne contient explicitement pas de données de mesure certifiées.

Livraisons — le journal d’activité

La page Livraisons est un historique en lecture seule, divisé en deux onglets :

• Livraisons sortantes — une ligne par tentative de livraison sortante : date, workflow, action, destination, résultat (Succès / Échec / Nouvelle tentative / Message non remis), nombre de tentatives, durée et éventuelles erreurs. Les exécutions de test sont signalées par un badge.
• Exécutions entrantes — l’historique des importations : source, résultat, date, durée, nombre de lignes et erreur.

Connexion rapide

Pour les intégrations courantes, l’assistant Connexion rapide vous guide à travers une recette plutôt que de vous laisser utiliser l’éditeur brut — par exemple : « Envoyer les nouvelles soumissions du portail vers mon système », « Alerter mon système lorsque le stock est faible », « Créer un ticket lorsqu’une alarme se déclenche » ou « Recevoir les relevés de mes capteurs ou de ma passerelle ». Il configure pour vous le connecteur, le hook ou la règle.

Autorisations

La fonctionnalité « Automatisations » n’utilise pas la grille globale des droits d’administrateur. Les trois pages de configuration (Automatisations, Identifiants, Livraisons) sont protégées par une liste blanche de utilisateurs autorisés à consulter / modifier dans les paramètres des automatisations ; vous accordez donc l’accès de manière explicite. La page Alarmes est volontairement accessible à tout utilisateur connecté — la surveillance des alarmes relève des opérations, et non de la configuration. Les détenteurs du droit « Paramètres de l’application » disposent toujours d’une solution de secours si les listes sont vides.