Nanoworks.io
Cas fondateur: une plateforme AI ops pour exécuter, gouverner et auditer des workflows IA entre cloud, on-prem et air-gap.
Le produit part du périmètre
J'ai construit Nanoworks comme un cas transversal: il oblige à tenir plusieurs métiers en même temps, produit, infra, sécurité, AI engineering, compliance, runbooks et discussion client.
Le produit part d'une contrainte que les équipes régulées connaissent bien. Elles veulent utiliser des workflows IA, mais elles doivent encore savoir qui a lancé quoi, quel modèle a répondu, quelles sources ont été utilisées, combien cela coûte, et où les données ont circulé.
L'architecture porte la vente
J'ai orienté le produit autour d'un choix: rendre les contraintes visibles au lieu de les cacher derrière une interface de chat. Les workflows doivent montrer leurs sources, leurs politiques, leurs coûts et leurs refus.
La stack suit cette idée. Kubernetes porte le déploiement. Temporal donne une exécution durable. MCP sert de connecteur vers les outils. OPA exprime les politiques. Le graphe de workflow rend les enchaînements lisibles pour les équipes qui doivent les exploiter.
Décrire le périmètre clientDéclarer les sources et les outils autorisésExécuter le workflow avec politiques avant/aprèsGarder la preuve exploitable par l'équipe qui porte le risqueLa gouvernance sans théâtre
Le travail de fond n'est pas seulement de lancer des agents. Il faut aussi mettre en place RBAC, audit trail, quotas, policy cascade, egress rules, identity, logs, métriques, evidence packs et chemins de reprise.
Cette partie est moins spectaculaire que la démo. C'est pourtant là que le produit devient vendable à une entreprise: le RSSI peut demander la preuve, les achats peuvent comprendre le modèle de coût, et l'équipe métier peut expliquer pourquoi une requête a été refusée.
Le produit devient sérieux quand le refus est aussi lisible que le succès.
Ce que ce cas démontre
Ce cas montre ma manière de travailler sur plusieurs couches: passer d'un schéma produit à une politique d'egress, d'un runbook Kubernetes à une discussion compliance, d'un prototype LLM à une architecture on-prem.
- Product judgment: transformer la souveraineté, le coût et l'audit en décisions visibles.
- Software engineering: tenir un cœur Rust/API, des contrats de configuration et des modules réutilisables.
- Infrastructure: penser les topologies T1 à T4 sans forker le produit.
- Consulting: traduire les objections sécurité, achats et métier en langage de livraison.