Trois obligations que nous assumons
Un agent qui agit sur des données de risque ne vaut que l’honnêteté des données qu’on lui donne. Un modèle qui renvoie allègrement un chiffre pour une question à laquelle il ne peut pas répondre finira par blesser quelqu’un. La plateforme doit donc trois choses à un agent, et les lui doit sous forme lisible par une machine.
- Une provenance par valeur. Pas un crédit en pied de page — une source et une licence qui voyagent avec la valeur elle-même, afin qu’un agent qui reproduit un chiffre puisse aussi en reproduire l’origine.
- Un âge par valeur. Chaque valeur indique quand elle a été mesurée. Rien n’est présenté comme direct ou certain sans l’être, et un agent peut décider lui-même si un champ de vent vieux d’une heure suffit à la question posée.
- Les refus comme valeurs. Quand une question sort de ce que nous mesurons, la réponse est un refus structuré qui porte son motif — pas un chiffre plausible, pas un résultat vide et silencieux. Certaines questions sont refusées nommément parce que mal y répondre est pire que de ne pas répondre : le conseil en renforcement parasismique en est une, et elle reste refusée.
Le registre est le contrat
Les promesses marketing ne coûtent rien ; un registre qu’un client peut interroger, si. OrbiVigil publie son propre registre de capacités — pour chaque produit et chaque marché, si la capacité est en service, en bêta ou prévue, calculé au moment de la requête plutôt que rédigé à la main. Toute affirmation de statut sur ce site est faite pour être vérifiée auprès de lui. Si une page dit « en service » et que le registre dit « prévu », c’est la page qui a tort.
Le même principe gouverne la surface de données. Les événements avec indice de confiance, les observations, les couches de vent et de danger qu’un agent consomme sont ceux-là mêmes que rend la carte en direct ; il n’y a pas de second jeu de données, plus flatteur, derrière la console. Un serveur Model Context Protocol expose cette intelligence sous forme d’outils, afin qu’un assistant IA puisse l’interroger directement sans compte.
Ce qui fonctionne aujourd’hui, et ce pour quoi l’architecture est conçue
Aujourd’hui. Le JSON ouvert, mis en cache à la périphérie, pour les événements, les observations, le vent et les couches de danger est en service. Le serveur MCP est en service. Le registre de capacités est en service et calculé à chaque requête. Une provenance lisible par machine, l’âge de la donnée et un niveau de confiance accompagnent les charges utiles, et c’est la validation par un analyste — jamais une promotion automatique — qui transforme une détection probable en événement confirmé.
Conçu pour, mais pas encore en service. Le même contrat est conçu pour être ce sur quoi un actif robotisé agit, et une norme unifiée de diffusion des alertes à travers chaque produit de risque est à la feuille de route. Les deux sont décrits comme prévus ici et sur la page d’accueil tant qu’ils ne servent pas.
Pourquoi cela compte pour un acheteur, et pas seulement pour un ingénieur
Une institution qui adopte l’IA doit, tôt ou tard, expliquer une décision. Un système dont chaque valeur arrive avec une source, un horodatage et une incertitude explicite est un système dont les décisions peuvent être reconstituées des mois plus tard devant un auditeur, un régulateur ou un tribunal. Ce n’est pas une fonctionnalité ajoutée pour les agents ; c’est la raison pour laquelle la plateforme est utilisable par une autorité.
À lire ensuite : le modèle du monde que lisent les agents ; l’IA physique — les actifs qui agissent dessus.