Fundamentum par Amotus
Le control plane de
gouvernance.
Pas un pipeline de données.
Les plateformes cloud répondent à : « Ce message peut-il être livré ? »
Fundamentum répond à : « Cette action doit-elle être autorisée ? »
Ce sont deux questions catégoriquement différentes. Les hyperscalers résolvent la première avec une efficacité remarquable. Aucun ne fournit la seconde — la couche de gouvernance qui décide ce qu’une flotte a le droit de faire. C’est pourquoi 74 % des projets IoT échouent.
Au-dessus
De tout hyperscaler
En dessous
De toute application
850K+
Appareils en production
L’architecture
Trois piliers. Un control plane.
Une architecture de gouvernance institutionnalise les règles qui vivent aujourd’hui dans la mémoire des ingénieurs qui ont bâti le système. À 500 appareils, cette mémoire suffit. À 5 000, elle échoue.
Identité
Qui agit ?
Des identifiants cryptographiques pour chaque acteur — appareils, utilisateurs, API et processus automatisés. Une identité vérifiable, avec une portée d’autorité définie. Quand un identifiant est compromis, le rayon d’impact est borné par son rôle.
Cycle de vie
Quand l’action est-elle permise ?
Dans une flotte gouvernée, un appareil n’est jamais simplement « en ligne » ou « hors ligne ». Il occupe un état défini — provisionné, activé, en maintenance, en attente de mise à jour, décommissionné. Les actions disponibles dépendent de cet état.
Politiques
Qu’est-ce qui est autorisé ?
Des jeux de règles versionnés, auditables et testables, appliqués au niveau de l’infrastructure — indépendamment du code applicatif. Une politique appliquée dans le code est une convention ; elle casse quand un développeur oublie l’appel. Une politique de gouvernance ne peut pas être contournée.
L’exemple concret
La mise à jour de micrologiciel gouvernée
Dans un système non gouverné, une mise à jour est une opération de publication. Dans Fundamentum, c’est un flux d’autorisation en quatre étapes.
01 · PRÉPARER
Empaqueter & signer
Micrologiciel signé, intégrité vérifiée. Portée cible et paramètres de déploiement définis. Seuils de santé établis.
02 · AUTORISER
Contrôle d’identité
Identité demandeuse vérifiée. Appareils cibles validés selon leur état. Second approbateur engagé si la politique l’exige.
03 · LIVRER
Déploiement progressif
Livraison par cohortes. Métriques de santé validées à chaque étape. Impossible de dépasser un seuil sans validation.
04 · VÉRIFIER
Auditer & confirmer
Retour arrière automatique en cas d’échec. Preuve cryptographique de chaque décision — qui a autorisé, quand, sous quelle version de politique.
Chaque action est inscrite dans la piste d’audit inviolable. La chronologie d’un incident se reconstruit à partir de preuves — pas d’archéologie de logs.
Pourquoi les hyperscalers ne résolvent pas ça
Le cloud, c’est l’infrastructure.
Fundamentum, c’est l’autorité.
La pile hyperscaler a été conçue pour résoudre la connectivité avec une efficacité remarquable. Elle n’a pas été conçue pour résoudre l’autorisation. Fundamentum est le système gouverné que vous bâtissez par-dessus cette infrastructure.
- Agnostique au cloud : peut s’interfacer avec AWS, Azure ou Google Cloud si vous l’exigez — sans enfermement
- Agnostique à l’application : l’application des règles ne peut être contournée par le code
- Connectivité flexible : Cellular (LTE-M, 5G), LoRaWAN, Wi-SUN, DigiMesh, Wirepas
- Intégrable par les OEM : la gouvernance comme couche produit, pas comme surcouche de service
Position dans la pile
Applications
Votre produit — web, mobile, API
Fundamentum
Control plane de gouvernance
Identité · Cycle de vie · Politiques
Infrastructure infonuagique
AWS · Azure · GCP · Souverain
Micrologiciel · Connectivité · Matériel
Conçus par Amotus pour la gouvernance dès le premier jour
