Chaque plateforme est le produit de ses décisions architecturales. Les fonctionnalités s'ajoutent et se retirent. L'architecture reste. Les choix que nous faisons au niveau des fondations déterminent ce qui sera possible — et ce qui sera impossible — pendant des années.

Cet article documente les décisions architecturales fondamentales du stack GRAL et le raisonnement derrière chacune d'elles. Ce ne sont pas les seuls choix possibles. Ce sont ceux qui fonctionnent le mieux dans le contexte où nous opérons : IA enterprise, données sensibles, exigences de production réelles.

On-Premise First

La décision architecturale la plus importante de GRAL est aussi la moins à la mode : on-premise first.

La plupart des plateformes IA naissent dans le cloud puis tentent de s'adapter au monde enterprise. GRAL a fait le chemin inverse. Nos plateformes sont conçues pour tourner sur l'infrastructure du client — dans leurs centres de données, sous leur contrôle, derrière leur pare-feu.

Pourquoi ? Parce que les données enterprise ne quittent pas l'entreprise. Pas par caprice, mais pour des raisons concrètes : réglementations sectorielles, clauses contractuelles avec les clients, exigences de souveraineté des données, politiques de sécurité interne. Quand une entreprise manufacturière nous dit que les données de production ne peuvent pas quitter l'usine, ce n'est pas une contrainte à contourner. C'est une exigence de conception.

L'approche on-premise first a un coût d'ingénierie significatif. Nous ne pouvons pas présumer un matériel homogène. Nous ne pouvons pas compter sur des services managés. Nous devons gérer l'installation, la configuration et les mises à jour dans des environnements qui varient énormément d'un client à l'autre. Mais le résultat est une plateforme qui s'adapte à l'infrastructure existante au lieu d'exiger que l'infrastructure s'adapte à elle.

Architecture Edge-Cloud Hybride

On-premise ne signifie pas monolithique. Le stack GRAL implémente une architecture edge-cloud hybride où l'inférence se fait à l'edge et l'entraînement se fait de manière centralisée.

À l'edge : Des noeuds d'inférence légers qui exécutent des modèles quantifiés près de la source de données. Dans le manufacturier, cela signifie du matériel dédié sur la ligne de production. Dans la logistique, cela signifie des noeuds dans les centres de tri. Latence inférieure à 15 ms, aucune dépendance au réseau pour les décisions critiques.

Au coeur : L'instance centralisée de Cognity ou Sentara qui gère l'entraînement, l'analytique, la mise à jour des modèles et l'orchestration. Elle peut résider dans le centre de données du client ou dans son cloud privé.

Le lien : Un pipeline de synchronisation asynchrone qui déplace les données d'entraînement de l'edge vers le coeur et les modèles mis à jour du coeur vers l'edge. Si la connexion s'interrompt, les noeuds edge continuent de fonctionner avec le dernier modèle disponible. Aucun point unique de défaillance.

Cette architecture résout un problème que le cloud pur ne peut pas résoudre : la latence déterministe. Quand un système de vision doit classifier une pièce à la vitesse de la ligne de production, il ne peut pas attendre un aller-retour vers le cloud. L'inférence doit se faire localement, avec des garanties de latence que seule l'exécution on-device peut offrir.

Orchestration Custom

GRAL n'utilise pas Kubernetes pour l'orchestration des workloads IA. Nous avons construit un orchestrateur custom.

C'est une décision qui nécessite une explication, car aller à l'encontre du standard industriel n'est pas un choix que l'on fait à la légère. Les raisons sont au nombre de trois.

Scheduling GPU-aware. Kubernetes traite les GPU comme des ressources génériques. Nos workloads IA ont besoin d'un scheduling qui comprend la topologie GPU — quels modèles bénéficient de la co-localisation, comment partitionner la mémoire GPU entre des workloads concurrents, quand migrer un workload sur un noeud différent pour équilibrer la charge thermique.

Gestion du cycle de vie des modèles. Le cycle de vie d'un modèle IA ne correspond pas au cycle de vie d'un container. Un modèle a des versions, des métriques de qualité, des fenêtres de validation et des procédures de rollback qui sont spécifiques au domaine. Notre orchestrateur gère le modèle comme un citoyen de première classe, pas comme un artefact dans un container.

Contraintes temps réel. Pour les workloads d'inférence edge, nous avons besoin de garanties de scheduling que Kubernetes ne peut pas offrir. Priorités hard real-time, pinning des coeurs CPU, gestion déterministe de la mémoire. Notre orchestrateur intègre ces garanties nativement.

Le coût est la maintenance d'un composant infrastructurel critique. Le bénéfice est un niveau de contrôle et d'optimisation qui n'est tout simplement pas possible avec des solutions génériques.

Modèle de Données Zero-Trust

Chez GRAL, chaque accès aux données est authentifié, autorisé et audité. Il n'y a pas d'exceptions.

Le modèle zero-trust s'articule sur trois niveaux :

  • Authentification — Chaque composant du système possède une identité cryptographique. Les noeuds edge s'authentifient auprès du coeur via des certificats mutuels. Les services internes s'authentifient entre eux. Aucune communication ne s'effectue sur des canaux non authentifiés.
  • Autorisation granulaire — Les politiques d'accès définissent qui peut lire quelles données, à quel niveau de granularité. Un modèle de vision par ordinateur peut accéder aux images de la ligne 3 mais pas de la ligne 7. Un agent Sentara peut lire les données du client mais pas les modifier. Les politiques sont déclaratives et versionnées.
  • Audit complet — Chaque accès aux données génère un enregistrement immuable. Qui a accédé à quoi, quand, pourquoi, avec quel résultat. Ce n'est pas du logging optionnel. C'est une partie intégrante du pipeline d'accès aux données.

Pour les clients dans des secteurs réglementés — finance, santé, défense — ce modèle n'est pas un nice-to-have. C'est un prérequis. L'avoir construit comme fondation architecturale signifie que la conformité n'est pas un ajout tardif, mais une propriété du système.

Approche de l'Intégration

Les plateformes GRAL ne vivent pas en isolation. Elles s'intègrent à l'écosystème enterprise existant — ERP, MES, CRM, systèmes legacy, bases de données propriétaires. L'approche de l'intégration est une décision architecturale critique.

Adapter pattern. Chaque intégration est implémentée comme un adapter qui traduit entre le modèle de données interne de GRAL et le système externe. Les adapters sont des composants indépendants, versionnés et testables. Quand un système externe change, seul l'adapter est modifié.

Event-driven, pas polling. Lorsque c'est possible, les intégrations sont event-driven. Les données circulent quand elles changent, pas quand quelqu'un les demande. Cela réduit la latence et la charge sur les deux systèmes.

Contrats API stables. Les interfaces entre GRAL et les systèmes externes sont définies par des contrats explicites et versionnés. L'évolution interne de la plateforme ne casse pas les intégrations existantes. C'est fondamental pour les clients qui ne peuvent pas se permettre de temps d'arrêt pendant les mises à jour.

Pourquoi ces Décisions

Chaque décision architecturale décrite ici naît d'une contrainte réelle de l'IA enterprise. On-premise first parce que les données ne se déplacent pas. Edge-cloud hybride parce que la latence compte. Orchestration custom parce que les GPU ne sont pas des commodités. Zero-trust parce que la conformité n'est pas optionnelle. Intégration-first parce que l'IA en isolation n'a pas de valeur.

GRAL n'a pas choisi ces architectures parce qu'elles étaient les plus élégantes. Nous les avons choisies parce que ce sont celles qui fonctionnent quand le système doit tourner en production, à grande échelle, dans des environnements enterprise réels.

La différence entre une architecture de tableau blanc et une architecture de production est la suivante : les décisions qui survivent au contact avec la réalité.