Aperture Venture Studio a déployé une architecture en trois étapes pour la création de plateformes IoT assistées par l'IA (AIoT) capables de servir plusieurs entreprises indépendantes simultanément.
Pourquoi une plateforme AIoT partagée est essentielle
La plupart des groupes d'ingénierie conçoivent une plateforme autour d'un produit unique, puis réutilisent certains de ses éléments pour des versions ultérieures. Un venture studio, en revanche, doit jongler avec plusieurs startups qui ciblent des clients différents, fonctionnent sur du matériel différent et évoluent selon des calendriers distincts. Sans une approche coordonnée, chaque projet reconstruit de zéro les mêmes pipelines de données, les mêmes piles d'entraînement de modèles et les mêmes services de gestion d'appareils. Cette duplication entraîne une perte de temps.
Le modèle en trois étapes
L'approche d'Aperture divise le cycle de vie en trois phases claires :
- Solution opérationnelle pour un client unique – Les équipes livrent un service AIoT fonctionnel qui répond à un besoin réel, établissant ainsi un cas d'usage concret et un ensemble d'exigences.
- Module réutilisable dans une plateforme partagée – La solution est refactorisée en un composant réutilisable qui s'intègre aux autres modules d'une plateforme commune. Cette étape est la plus difficile car le code doit être suffisamment abstrait pour prendre en charge des domaines disparates tels que le suivi d'actifs, la sécurité des travailleurs ou la surveillance environnementale.
- Candidat à l'autonomisation (spin-out) – Lorsqu'un projet est prêt à devenir sa propre entreprise, il remplace l'infrastructure partagée par une instance privée qui implémente les mêmes interfaces, permettant au code de fonctionner sans modification.
L'étape intermédiaire constitue le plus gros du travail. Les équipes créent une couche de base de modèles d'IA qui peuvent être affinés (fine-tuned) plutôt qu'entraînés à partir de zéro pour chaque nouveau projet. Traiter les modèles de base comme des actifs partagés signifie que toute amélioration du modèle de base profite instantanément à tous les projets qui s'appuient sur lui.
Des pipelines de données partagés sans isolation complète
Une tentation courante consiste à isoler complètement le pipeline de données de chaque client (tenant), en supposant que cela permet de séparer proprement les projets. Aperture avertit qu'une isolation totale bloque le flux d'améliorations : un correctif de bug ou une nouvelle routine de nettoyage de données appliquée à un pipeline ne parvient jamais aux autres. Leur approche hybride résout ce problème :
- Données clients séparées – Les données brutes de chaque projet restent dans son propre compartiment de stockage (storage bucket), préservant ainsi la confidentialité et la conformité.
- Logique de traitement partagée – Le code commun qui nettoie, débruite et structure les données réside dans une bibliothèque unique. La mise à jour de cette bibliothèque profite automatiquement à chaque projet.
- Règles spécifiques au projet – Les cas particuliers sont gérés par de petits ensembles de règles de type « plug-in » qui se superposent à la logique partagée, maintenant la stabilité du cœur tout en permettant la personnalisation.
Cette conception garantit la souveraineté des données tout en tirant parti d'une logique de traitement partagée.
Le découplage pour une autonomisation sans douleur
Le couplage fort s'installe lorsque les équipes s'appuient sur des API internes qui n'existent qu'au sein de l'écosystème du studio. Aperture combat cela en imposant des interfaces strictes pour toutes les dépendances. Chaque module déclare les contrats dont il a besoin — que ce soit pour la communication avec les appareils, l'inférence de modèles ou la facturation — et rien de plus.
Lorsqu'un projet atteint l'étape de l'autonomisation, il lui suffit de pointer ces interfaces vers ses propres implémentations. Comme le code n'a jamais appelé directement un service interne concret, le remplacement devient une simple question de configuration plutôt qu'une réécriture complète. Planifier ce découplage tôt permet d'éviter une réarchitecture coûteuse par la suite.
Risques et contre-arguments
Le modèle d'infrastructure partagée n'est pas une solution miracle.
À surveiller ensuite
À retenir : La création d'une plateforme AIoT partagée dotée d'interfaces claires, d'une base de modèles commune et d'une stratégie de pipeline de données hybride permet aux venture studios de lancer plusieurs startups plus rapidement et de les autonomiser proprement.