Le contrat entre leurs champs et les nôtres.
Chaque intégration est une correspondance que vous concevez à partir d’un vrai dossier collé depuis l’autre système — et un essai à blanc qui nomme quatre choses avant que vous lui fassiez confiance : ce qui arriverait, ce qui manque, ce qu’ils envoient et que rien ne lit, et quelles transformations échouent sur la valeur réelle. « Écarté en silence » est la phrase que cet écran existe pour supprimer.
Bilingue FR / EN · Contrat d’API publié · WCAG 2.2 AASix éléments font une intégration
Une intégration ici n’est pas un interrupteur qu’on active en croisant les doigts. C’est un contrat entre les champs de quelqu’un d’autre et les vôtres — mis par écrit, vérifié par des preuves, et refusé tant qu’il ne tient pas.
Une entité
Fournisseurs, pièces, actifs ou bons de travail. Leur dossier d’un côté, le nôtre de l’autre, et le contrat entre les deux.
Une direction
Entrante ou sortante, consignée dans le contrat et affichée dans le registre à côté du système avec lequel il communique.
Un vrai échantillon
Un dossier réel, collé depuis l’autre système. C’est ce que consomme l’essai à blanc — tout ce qui suit est calculé exactement à partir de lui.
Correspondances de champs
Leur champ tel qu’il apparaît dans l’échantillon, notre champ choisi parmi ce que l’entité offre, et l’une des cinq transformations appliquée en direct.
Les champs obligatoires, marqués
Un fournisseur entrant sans nom n’est pas un fournisseur, c’est une ligne de bruit — les champs obligatoires portent donc un badge sur la ligne et un refus au contrôle.
Un état
Ébauche tant que chaque blocage nommé n’est pas levé. L’activation dépend exactement du calcul que le panneau d’essai à blanc vous montre déjà.
Quatre listes, et aucune n’est facultative
Collez un vrai dossier et le panneau répond immédiatement : ce qui arriverait, avec la valeur réellement produite par la transformation; ce qui est associé mais absent de l’échantillon; ce que l’autre côté envoie et que rien de votre côté ne lit; et quelles transformations ont échoué sur la valeur réelle plutôt que sur le type promis.
- La valeur, pas le nom de la transformation — “
devise = CAD ← WAERS» montre ce que la mise en majuscules a fait à la chaîne réelle : une mauvaise transformation est donc visible plutôt que plausible. - Les champs associés mais manquants sont signalés, jamais ignorés — une correspondance qui lit un champ qu’ils n’envoient pas, c’est une colonne de blancs en production, découverte un mois plus tard.
- Ce qu’ils envoient et que rien ne lit est nommé — c’est la liste qui attrape le champ que quelqu’un a ajouté à l’exportation le trimestre dernier sans en parler à personne.
- Les transformations en échec indiquent la valeur —
« not recorded » n’est pas une date, plutôt que « type incompatible pour le champ 7 ». - Recalculé à chaque frappe — modifiez l’échantillon ou changez une transformation et les quatre listes bougent sous vos yeux : l’échec arrive ici plutôt qu’en production.
Ébauche tant que chaque blocage nommé n’est pas levé
Un contrat que vous ne pouvez pas vérifier est un contrat dont vous entendez parler en production, habituellement par quelqu’un d’un autre service. L’activation est donc refusée tant que l’essai à blanc ne revient pas propre, et chaque refus nomme son propre champ plutôt que d’annoncer que quelque chose, quelque part, est invalide.
- L’échantillon doit être en JSON — sinon rien ne peut être vérifié, et le panneau le dit exactement plutôt que d’afficher quatre listes vides.
- Chaque champ obligatoire doit être associé — nommément, pour que la correction soit évidente plutôt qu’une chasse dans un schéma.
- Chaque correspondance doit trouver son champ — dans l’échantillon que vous avez collé, la seule preuve dont quiconque dispose.
- Chaque transformation doit résister à la valeur réelle — celle qui est réellement arrivée, pas celle que la spécification promettait.
- Les champs non lus ne bloquent jamais — ce qu’ils envoient et que personne ne consomme est une information utile, pas une erreur qui justifie un arrêt.
Un contrat publié, et un client généré à partir de celui-ci
Sous le concepteur de correspondances se trouve une vraie API : un client typé construit à partir d’un document OpenAPI, qui utilise la même enveloppe que le produit utilise déjà en interne. Déplacer un écran vers le serveur change l’endroit où se trouve la vérité, pas la façon dont l’écran la demande.
Un refus qui passe par le réseau ressemble à un refus en mémoire
Un succès revient sous forme de valeur; un refus revient sous forme de raison avec les champs qu’il nomme — et un 422 du serveur apparaît comme le même résultat typé qu’une commande interne renvoie. C’est ce qui permet de déplacer un écran vers le serveur sans le réécrire autour d’une nouvelle convention d’erreur.
- Un 401 arrive dans la même enveloppe — l’interface peut ainsi distinguer « votre session a pris fin » de « quelque chose s’est brisé », deux phrases différentes à montrer à quelqu’un.
- L’absence du serveur est un état, pas une exception — « injoignable » est une raison comme une autre, et la console l’affiche comme telle plutôt qu’en pile d’appels.
- Le jeton est relu à chaque requête — un client qui garde la valeur reçue à sa construction continue d’envoyer un jeton révoqué il y a dix minutes.
- Le transport est injecté, pas importé — les tests lui fournissent une imitation et le navigateur, la vraie chose, ce qui le rend aussi utilisable depuis un script ou une application terrain.
- Les blocages reviennent sous forme de liste — le point de terminaison d’acceptation refuse avec les mêmes blocages que ceux qu’applique le registre : l’API et l’écran ne peuvent donc pas être en désaccord sur la raison.
Rediriger un site en production sans tout reconstruire
L’endroit où l’interface croit que se trouve le serveur est déterminé à trois endroits, dans l’ordre — un site déployé peut donc être pointé vers une autre API en modifiant un seul fichier, plutôt qu’en reconstruisant et redéployant tout le paquet pour changer une URL.
- D’abord le choix de ce navigateur — défini dans la console du serveur pour un développeur sur une branche, et jamais propagé dans la session de quelqu’un d’autre.
- Ensuite un fichier de configuration à côté de la page — celui qui compte en production : un site statique est redirigé en modifiant un seul fichier dans le stockage.
- Ensuite une valeur intégrée au moment de la compilation — pour les déploiements qui préfèrent la figer plutôt que de livrer un fichier de configuration.
- La valeur par défaut en développement est localhost, délibérément — un site déployé sans configuration doit échouer à trouver une API plutôt que de trouver par accident celle de quelqu’un d’autre.
- L’identité a sa propre adresse — la connexion et l’API des registres sont des services différents, et partager une même URL de base pointerait l’écran de connexion vers un serveur sans points de terminaison de connexion.
Les relevés entrent. Rien ne ressort.
Un point provenant d’un système d’automatisation du bâtiment ou d’un contrôleur, associé à un compteur, avec une transformation linéaire lisible sur la ligne. La limite est délibérée, et elle est affichée à l’écran plutôt qu’enfouie dans une fiche technique : les relevés entrent dans Zenith, et rien ici ne renvoie de commande ou de consigne à un appareil.
Un relevé d’appareil obéit à toutes les règles d’un relevé saisi
Les relevés arrivent par la commande propre au registre des compteurs — la même porte que celle d’une personne qui saisit un relevé pendant une tournée. Un relevé qui recule sur un compteur cumulatif, ou qui arrive avec une valeur invraisemblable, est donc refusé par le registre plutôt qu’accepté parce qu’une machine l’a envoyé.
- La transformation est sur la ligne, pas dans une procédure stockée — le panneau rapporte des kPa et le compteur est en Pa; l’échelle est donc de 1000 et vous pouvez la voir, la contester et la modifier.
- Les tentatives refusées sont conservées, bien en vue — avec la raison donnée par le registre, dans ses propres mots.
- Entrant seulement, et l’écran le dit — un badge sur la page, parce qu’une limite que personne ne voit est une limite que quelqu’un finira par ignorer.
- Le journal d’exécution est déjà la porte — le même journal dans lequel écrira un vrai répartiteur; l’historique ne repartira donc pas à zéro le jour où le transport arrivera.
Ce qui est conçu, et ce qui relève de la moitié serveur
Un module d’intégration est la chose la plus facile à vendre sur un diagramme dans un système de maintenance. Celui-ci trace la ligne là où son propre code la trace — et l’affiche au bas du registre plutôt que de vous laisser la découvrir au quatrième mois.
- Les noms de transport sont consignés, et honnêtes à ce sujet — REST, dépôt de fichiers et webhook figurent sur le contrat; le répartiteur qui les parle relève de la moitié serveur.
- L’API en dessous n’est pas une imitation — un vrai client typé sur un contrat publié, qui gère déjà la connexion, les sessions et les refus.
- Rien n’est déguisé en connecté — un écran qui n’a pas encore migré vers le serveur le dit, à l’écran.
- Le contrat est la partie qui doit être juste en premier — un calendrier pointé vers une correspondance que personne n’a vérifiée échoue simplement plus vite et plus souvent.
Tout ce qui entoure la correspondance
Cinq transformations
Tel quel, majuscules, minuscules, date au format ISO et nombre — chacune appliquée en direct à l’échantillon : celle que vous choisissez est jugée sur la valeur réellement arrivée.
Vingt champs cibles
Cinq par entité, avec les champs incontournables marqués d’un badge sur leur propre ligne plutôt que découverts au contrôle.
Un seul contrat de requête
Recherche, filtres, tri et pagination dans un même document partagé — celui que les registres parlent déjà : un écran demande donc au serveur exactement ce qu’il demandait à la mémoire.
Les modifications s’appliquent sur place
Changez une transformation et l’essai à blanc se met à jour en dessous. Il n’y a pas de bouton Enregistrer à oublier ni d’ébauche à rapprocher.
Une vérification de santé qui répond
Elle indique quel magasin d’identités a répondu — celui de production ou celui d’exemple — pour que « suis-je en production? » cesse d’être une supposition lors d’un appel de soutien.
Généré, pas écrit à la main
Le client est produit à partir du document OpenAPI par un générateur : le contrat publié et le code qui l’appelle ne peuvent donc pas diverger en douce.
Une connexion qui résiste au changement
Sessions, groupes, appartenance aux sites et changement de mot de passe forcé passent tous par le même client — avec le jeton relu à chaque appel plutôt que capturé une seule fois.
Vos mots, partout
La direction, l’entité et le statut passent tous par votre propre vocabulaire : un contrat se décrit dans les termes que votre organisation utilise déjà.
Deux langues, jusqu’au bout
Chaque libellé, indication, état vide et blocage existe en français et en anglais — y compris la phrase qui vous dit qu’un contrat ne peut pas encore être activé.
Vérifiable avant que quoi que ce soit bouge
Les intégrations échouent en silence, des mois après que plus personne ne surveille, et l’analyse après incident est toujours la même : un champ que personne n’a associé, une valeur que personne n’a validée, un message que personne n’a conservé. Tout ici est conçu précisément contre ces trois défauts.
Des preuves, pas des suppositions
Un contrat est jugé sur un vrai dossier que vous avez collé, pas sur une spécification que quelqu’un a écrite au sujet de ce dossier.
Une seule enveloppe, des deux côtés
Un refus en mémoire et un refus transmis par le réseau ont la même forme : rien n’est réécrit quand un écran migre vers le serveur.
Bilingue dès sa conception
Parité complète en-CA / fr-CA sur chaque écran, indication, état vide et refus — les pluriels gérés correctement, pas par concaténation.
Accessible à tous
WCAG 2.2 AA comme règle de conception : de vrais tableaux sémantiques, des états annoncés en mots, et un focus qui se déplace vers le champ visé par une erreur.
Avant de réserver la démo
Avez-vous un connecteur SAP?
Y a-t-il une vraie API, ou seulement des correspondances?
Quels formats pouvez-vous accepter?
Peut-on associer des champs imbriqués ou des tableaux?
customer.address.city et les groupes répétitifs ne sont pas pris en charge, et des données qui forment un tableau de dossiers ne peuvent pas du tout être testées à blanc. Si votre exportation est imbriquée, la réponse honnête pour l’instant est de l’aplatir à la sortie.
Y a-t-il des valeurs par défaut, des tables de correspondance ou des transformations personnalisées?
CLSD en votre statut Fermés. Une couche de correspondance dotée d’un langage d’expressions est une couche que personne ne peut lire à trois heures du matin — et l’essai à blanc ne reste lisible que parce que chaque ligne est un champ et une règle. La traduction de valeurs est une demande raisonnable, et elle est sur la liste.
Que se passe-t-il quand le serveur est injoignable?
Un site déployé peut-il être pointé vers une autre API?
Écrivez-vous dans un SGB, ou envoyez-vous des consignes?
Les relevés d’appareils échappent-ils à la validation habituelle?
Et la planification, les nouvelles tentatives et l’historique des exécutions?
Un contrat est-il versionné ou audité?
Par où commencer?
Apportez une ligne de l’autre système.
Un fournisseur de SAP, une exportation de bon de travail, une ligne d’une liste de points de SGB. Collez-la et nous ferons la correspondance devant vous — et l’essai à blanc vous dira sur-le-champ lesquels de leurs champs rien de votre côté ne lit, et lesquels des vôtres rien ne fournit.
Ailleurs dans Zenith
Guides sectoriels canadiens
Normes et organismes de réglementation
Les normes sont citées uniquement par numéro, titre et portée. Les publications CSA et ULC sont payantes — lisez la norme elle-même avant de bâtir un programme de conformité sur un résumé.