Architecture IA hors ligne pour la sécurité industrielle au Pakistan

Un opérateur pétrolier et gazier au Pakistan a mis en œuvre un système d'intelligence artificielle entièrement hors ligne (air-gapped) pour prédire les incidents liés à la santé, à la sécurité et à l'environnement avant qu'ils ne se produisent. Le projet, détaillé dans une architecture de référence publiée le 3 octobre 2026, repose exclusivement sur des modèles auto-hébergés et une infrastructure locale afin de garantir que aucune donnée opérationnelle sensible ne quitte le contrôle de l'entreprise. Cette approche démontre comment l'industrie lourde peut tirer parti de l'IA avancée tout en respectant des exigences strictes en matière de souveraineté des données.

Ce qui s'est passé

L'opérateur visait à transformer son département de sécurité, passant d'une logique de reporting réactif à une logique d'alerte proactive. Les données nécessaires à cette initiative existaient déjà, mais étaient cloisonnées entre les systèmes SAP EHS, les réseaux SCADA, les historiens de détection incendie et gaz, les flux vidéo des caméras et les fichiers d'enquête numérisés. La contrainte principale était qu'aucune de ces informations ne pouvait être envoyée vers des API d'IA tierces ou des services cloud. Chaque composant du chemin de service devait rester au sein de l'infrastructure physique propre à l'opérateur.

Pour répondre à ces besoins, l'équipe d'ingénierie a sélectionné des modèles basés sur des licences ouvertes autorisant une utilisation interne sans dépendances externes. Le moteur de raisonnement central utilise GLM 5.3, un modèle mixture-of-experts de 753 milliards de paramètres fonctionnant avec une précision FP8. Pour la détection d'anomalies sur séries temporelles, le système emploie Amazon Chronos-2, tandis que RF-DETR-Large de Roboflow gère la détection visuelle. La reconnaissance optique de caractères est assurée par PaddleOCR-VL-1.6 de PaddlePaddle, et la récupération multilingue prend en charge l'anglais, l'ourdou et l'ourdou romanisé via le modèle bge-m3 de BAAI.

Le dimensionnement matériel a été calculé en fonction des poids des modèles plutôt que des spécifications marketing. Le modèle GLM 5.3 nécessite environ 904 Go de mémoire avec une marge de sécurité, ce qui tient sur un nœud unique équipé de huit cartes accélératrices de 141 Go. Cette configuration laisse suffisamment de mémoire pour les caches clé-valeur et les utilisateurs simultanés. Les nœuds périphériques gèrent localement la détection et la prévision en temps réel, garantissant la poursuite des opérations même si le lien avec la couche centrale est interrompu.

Détails clés

• Le système utilise les poids ouverts de GLM 5.3 pour le raisonnement, sous licence pour un usage purement interne sans examen par un service managé.
• Le coût matériel pour posséder l'installation sur trois ans est estimé à 670 000 $, nettement inférieur à la location de GPU cloud équivalents.
• Toutes les sources de données se connectent via des adaptateurs en lecture seule qui étiquettent la provenance et mappent vers un modèle objet unifié.
• Apache Kafka sur KRaft ordonne les événements par clé d'équipement pour maintenir une exactitude chronologique lors de l'analyse des incidents.
• La synchronisation horaire est gérée par Chrony avec un grandmaster GNSS pour empêcher la dérive des horodatages entre les capteurs et les serveurs.
• La conception évite les points de contrôle (checkpoints) RF-DETR plus grands que Large en raison des restrictions de licence sur les versions supérieures.

Contexte

Les systèmes hors ligne (air-gapped) sont isolés des réseaux non sécurisés, tels que l'internet public, pour protéger les données sensibles. Dans les environnements industriels, cette isolation est critique pour les technologies opérationnelles qui contrôlent des processus physiques. L'exécution d'IA dans de tels environnements nécessite l'auto-hébergement de tous les modèles, car l'appel d'API externes romprait la rupture physique (air gap). Cela signifie que l'organisation doit gérer l'ensemble du cycle de vie du logiciel, y compris les moteurs d'inférence, les bases de données vectorielles et les mises à jour des modèles.

Le dimensionnement du matériel pour les grands modèles de langage implique de calculer la mémoire requise pour les poids du modèle ainsi que l'espace supplémentaire nécessaire pour les activations et les caches clé-valeur pendant l'inférence. Les formats de précision comme FP8 réduisent l'utilisation de la mémoire par rapport à FP16 ou FP32, permettant aux modèles plus grands de tenir sur le matériel disponible. Cependant, cela nécessite un support spécifique des accélérateurs et une planification rigoureuse pour garantir que les performances ne souffrent pas sous charge.

Pourquoi c'est important

Pour les équipes exécutant leur propre logiciel, cette architecture met en évidence les avantages tangibles en termes de coûts de l'auto-hébergement par rapport à la location cloud pour des charges de travail stables et volumineuses. Le coût de possession du matériel sur trois ans était moins de la moitié du coût de location de ressources équivalentes auprès d'un fournisseur cloud majeur dans la région des Émirats arabes unis. De plus, l'utilisation de modèles frontière fermés facturés au token aurait coûté entre 1,04 million et 2,95 millions de dollars pour cinquante utilisateurs, faisant de l'auto-hébergement l'option la plus économique pour un déploiement à long terme.

La souveraineté des données est un autre facteur critique. Puisqu'aucun hyperscaler n'opère de région au Pakistan, toute solution basée sur le cloud nécessiterait de déplacer les données à l'étranger, violant les contraintes de sécurité de l'opérateur. En maintenant tout traitement local, l'opérateur conserve un contrôle total sur sa propriété intellectuelle et ses données opérationnelles. Cette approche élimine également la dépendance à la disponibilité des API externes, assurant une continuité de service indépendamment de la connectivité internet ou de l'état des services tiers.

L'utilisation de modèles open-source avec des licences permissives permet à l'opérateur d'affiner et de modifier les poids selon ses besoins. Cette flexibilité est essentielle pour adapter des modèles génériques à des contextes industriels spécifiques, tels que la reconnaissance de configurations d'équipements uniques ou la compréhension de protocoles de sécurité localisés. Elle garantit également que l'organisation possède les capacités d'IA qu'elle construit, plutôt que de les louer à un fournisseur.

Ce que vous pouvez faire

• Auditez vos sources de données actuelles pour identifier les informations cloisonnées qui pourraient bénéficier d'une analyse IA unifiée.
• Évaluez les modèles à poids ouverts qui permettent une utilisation interne sans nécessiter d'appels d'API externes ou de services managés.
• Calculez les exigences matérielles en fonction du nombre de paramètres des modèles et des formats de précision, plutôt que des recommandations des fournisseurs.
• Implémentez des adaptateurs en lecture seule pour les systèmes existants afin d'assurer l'intégrité des données et le suivi de la provenance.
• Utilisez des protocoles de synchronisation horaire précis comme Chrony avec des sources GNSS pour corréler les événements entre les capteurs distribués.
• Comparez le coût total de possession (TCO) du matériel auto-hébergé avec celui de la location cloud.