CUBER, plateforme de simulation et de prototypage d’entreprise propulsée par l’IA
Une plateforme orchestrée par l’IA qui mène un projet d’entreprise de l’étude de marché jusqu’aux investisseurs.
Le projet
Cuber est un système d’exploitation d’entreprise de niveau professionnel, orchestré par l’IA, qui réunit tout le cycle de vie d’un projet entrepreneurial — de la veille marché et de la planification stratégique à l’exécution opérationnelle et à la préparation des investisseurs — dans une seule plateforme modulaire. La plateforme propose 19 modules indépendants, répartis en trois pôles : - Boîte à outils startup (9) | Moteurs stratégiques pilotés par l’IA | Analyse de sentiment, idéation JTBD, moteur de stratégie, générateur de pitch deck, executive summary | - Opérations (4) | Gestion opérationnelle | Hub d’exécution (Kanban), messagerie sociale unifiée, CRM, gestion des ressources - Outils (6) | Utilitaires autonomes | Email Pro (SMTP), générateur de landing pages, pôle juridique, visioconférence Ce qui rend l’architecture de Cuber unique : chaque module fonctionne comme une unité autonome et atomique, mais n’importe quelle combinaison de modules peut être assemblée à la volée pour produire des livrables agrégés à forte valeur. Un utilisateur peut lancer le moteur de stratégie seul, puis, des semaines plus tard, fusionner ses données dans un pitch deck qui puise aussi dans l’analyse de sentiment et le Founder-Market Fit, sans une seule ligne de code d’intégration.
Ce qu’il fait
Orchestration de l’intelligence entre les modules
L’aspect le plus exigeant techniquement de Cuber est la circulation des données entre les modules. La plateforme met en œuvre un Context Loader centralisé : une fonction unique qui résout, en un seul aller-retour parallélisé vers la base de données, six sources de données distinctes :
- Identité du projet, secteur, langue, marché cible
- Hypothèses validées du modèle économique
- Points de friction et de satisfaction du marché, et analyse des manques
- Persona client et job fonctionnel principal (JTBD)
- Propositions de valeur classées par score d’adéquation
- Avantage concurrentiel durable, angle d’attaque, marché tête de pont et concurrents
Chaque module propulsé par l’IA (stratégie, pitch deck, Founder-Market Fit, go-to-market, executive summary) consomme ce contexte partagé. Le loader utilise des requêtes parallélisées et garantit une résolution du contexte en moins de 100 ms, quel que soit le volume de données.
Décision d’ingénierie clé : lors des migrations de schéma, les anciens alias de données sont conservés à côté des noms de colonnes canoniques, ce qui permet aux générateurs de prompts existants de continuer à fonctionner sans modification. Ce principe de rétrocompatibilité a éliminé le risque de régression sur plus de 17 routes IA.
Moteur de couverture des données et contrôle intelligent
Le module Executive Summary agrège 13 sources de données indépendantes dans un document de qualité investisseur. Plutôt que d’échouer silencieusement en cas de données manquantes, le système intègre un calculateur quantitatif de couverture qui mesure la complétude de toutes les sources.
Le système refuse la génération sous un seuil de couverture configurable, ce qui évite de gaspiller des tokens LLM sur des données incomplètes. Lorsque la couverture est insuffisante, la réponse renvoie la liste exacte des modules manquants, et l’interface affiche une liste ciblée d’actions à compléter. Ce principe réduit nettement les coûts d’inférence tout en guidant l’utilisateur vers des données complètes.
Génération IA adaptée à l’audience
Les modules Pitch Deck et Executive Summary reposent sur un système d’audiences polymorphe. L’Executive Summary prend en charge 7 profils d’audience distincts (VC, business angel, banque, subvention, incubateur, conseil d’administration interne, général), qui définissent chacun :
- Le persona : l’état d’esprit de l’évaluateur (par exemple « Associé d’un fonds VC de premier rang évaluant un investissement en amorçage »)
- La consigne de ton : elle contrôle le vocabulaire et les points d’insistance (par exemple « Prudent, attentif aux risques, centré sur les flux de trésorerie » pour les banques)
- La pondération des sections : elle rééquilibre des sections entières du document (les banques privilégient la vue financière ; les incubateurs, la validation du marché)
Le Pitch Deck va plus loin avec des schémas de slides propres à chaque audience : indicateurs prioritaires, poids des slides, format de la slide de demande et suggestions de vocabulaire, tous injectés dans le prompt système du LLM. Un pitch destiné à un fonds VC se lit ainsi de façon fondamentalement différente d’un pitch destiné à un comité de subvention publique, même à partir des mêmes données de projet.
Architecture modulaire non linéaire (Tool Hub)
La plateforme a résolu un problème d’UX fondamental : 19 modules étaient bloqués derrière un parcours d’onboarding obligatoire, alors que 10 d’entre eux (53 %) ne dépendaient en rien des données d’onboarding.
L’équipe d’ingénierie a mis en place un principe de « projet fantôme » : une procédure stockée PostgreSQL légère qui crée une ligne de projet valide avec seulement 0 à 5 champs, ce qui permet de lancer n’importe quel module en moins de 200 ms. La solution a nécessité :
- Un registre d’outils centralisé (plus de 560 lignes) qui définit pour chaque module son niveau de dépendance, ses champs de saisie, ses règles d’affichage conditionnel et sa correspondance de persistance
- Des bannières intelligentes à trois niveaux d’escalade (
info → recommended → required) qui détectent à l’exécution les dépendances manquantes entre modules - Une procédure stockée de fusion de projets qui transfère les données de façon transactionnelle sur plus de 10 tables relationnelles lorsqu’un utilisateur regroupe ses travaux autonomes dans un espace de travail unifié
Toute la migration s’est faite sans aucune régression sur le parcours d’onboarding classique : toutes les Server Actions et routes d’API IA ont continué de fonctionner sans modification.
Moteur d’exécution avec automatisation des workflows
Le Hub d’exécution n’est pas un simple tableau Kanban. Il intègre :
- La détection des cycles de dépendances : un algorithme de parcours de graphe empêche les dépendances circulaires entre tâches en parcourant la liste d’adjacence, avec blocage des références entre projets
- Des workflows de validation : les tâches peuvent être confiées à un valideur désigné qui approuve ou rejette, ce qui déclenche des notifications par e-mail localisées (9 langues) à tous les intervenants RH et sous-traitants concernés
- Un contrôle d’accès fin au niveau de chaque outil : le système d’invitation permet de restreindre les droits par service, par tâche, par statut et par onglet, pour qu’un porteur de projet partage le tableau d’exécution avec un sous-traitant externe limité à son propre périmètre
Comment il est construit
Architecture de sécurité — défense en profondeur
Chaque Server Action du code passe par une barrière de sécurité obligatoire à plusieurs niveaux :
- Validation de schéma — Rejet des données malformées dès l’entrée grâce à une vérification stricte des types à l’exécution
- Contrôle d’accès — Vérification de l’authentification et de la propriété ou de l’appartenance au projet (contrôles parallélisés)
- Limitation de débit — Algorithme de token bucket par utilisateur et par opération, contre l’abus des services coûteux
- Assainissement — Tout contenu issu des utilisateurs est assaini avant traitement ou envoi au LLM
Validation des entrées : les plus de 60 Server Actions valident leurs entrées via des schémas stricts à l’exécution. Un seul module définit plus de 13 schémas couvrant les opérations CRUD, les notifications et les invitations, avec validation des UUID, listes blanches d’énumérations, longueurs maximales et analyse souple des dates. Un parseur partagé et typé renvoie des unions discriminées : pas d’exceptions, pas de catch non typés.
Contrôle d’accès : une garde centralisée vérifie les droits de l’utilisateur authentifié par des contrôles parallélisés sur les tables de propriété et d’appartenance. La fonction renvoie des résultats typés avec des codes de statut HTTP (401/403/404), pour une propagation cohérente des erreurs sur toute la plateforme.
Limitation de débit : un algorithme de token bucket protège toutes les opérations coûteuses (inférence LLM, scraping web, transcription). Chaque compteur est propre à un utilisateur et à une opération, ce qui empêche un utilisateur abusif de pénaliser les autres. L’algorithme calcule précisément la restauration des jetons en fonction du temps écoulé.
Ingénierie des pipelines LLM — sécurité des prompts
Le code met en œuvre un système de sécurité des prompts à plusieurs couches, un niveau de durcissement rarement vu en dehors des produits IA d’entreprise :
- Sentinelle au niveau système : chaque appel au LLM reçoit un prompt système immuable qui déclare tout contenu issu des utilisateurs comme non fiable et interdit au modèle de suivre des instructions ou des jeux de rôle intégrés
- Isolation du contenu : tout texte provenant des utilisateurs est encadré par des délimiteurs structurés. L’enveloppe échappe activement les délimiteurs dissimulés pour empêcher toute évasion
- Masquage des données personnelles : avant d’atteindre le LLM, tout texte utilisateur passe par un filtre qui supprime les identifiants personnels (e-mails, numéros de téléphone, URL), pour éviter leur conservation dans les journaux des fournisseurs externes
- Anonymisation des auteurs : pour l’analyse des réseaux sociaux, les noms d’utilisateur sont remplacés par des pseudonymes déterministes générés par une fonction de hachage, qui préservent les regroupements sans exposer les vraies identités
- Données canoniques côté serveur : tous les points d’évaluation IA relisent les données canoniques en base au lieu de faire confiance au texte envoyé par le client, ce qui élimine les vecteurs d’injection de prompt
Observabilité structurée
La plateforme intègre un logger structuré sur mesure qui produit des données sérialisables en JSON, exploitables par les services d’agrégation de logs (compatibles Datadog, ELK et les services de logs cloud natifs) :
Masquage automatique des clés sensibles connues avant sérialisation
- Troncature des chaînes et réduction des tableaux pour éviter l’inflation des logs
- Journalisation par portée et par niveau (info/warn/error) avec des objets de contexte horodatés
Ainsi, même en cas d’erreur, aucune donnée sensible ne fuit dans les flux de logs.
Architecture de la base de données — PostgreSQL et Row-Level Security
La couche de données repose sur PostgreSQL et des politiques de sécurité au niveau des lignes (RLS) qui imposent l’isolation des locataires au niveau du moteur de base de données. Principaux choix d’architecture :
- Procédures stockées transactionnelles : les opérations critiques sur plusieurs tables sont implémentées sous forme de fonctions atomiques, ce qui garantit la cohérence des données même lors de fusions complexes, de transferts en masse ou d’opérations de maintenance planifiées
- Modèle de données unifié : l’équipe a mené une migration de schéma importante qui a fusionné deux tables d’entités parallèles en une table unique avec un discriminant de type. Cette migration a touché plus de 11 fichiers sur toute la stack, sans aucune rupture
- Requêtes parallèles : les requêtes sont systématiquement regroupées en allers-retours parallèles. Les modules agrégateurs résolvent 5 à 6 requêtes simultanément avant de construire les prompts LLM, ce qui réduit la latence
Monorepo et infrastructure de build
Le projet utilise un monorepo Turborepo avec des workspaces pnpm :
- Application web — Next.js 16, App Router, React 19, Server Actions
- Application mobile compagnon — React Native
- Paquets partagés — Bibliothèques utilitaires typées, client de base de données typé
- Base de données — Migrations PostgreSQL, Edge Functions, procédures stockées
La chaîne de build met en cache de façon agressive par hachage du contenu et gère les variables d’environnement de 8 services externes (LLM, OCR, scraping web, signature électronique, paiements, e-mail, médias, analytics).
Ingénierie frontend
La couche d’interface repose sur une architecture orientée composants, construite avec :
- Les primitives Radix UI (plus de 20 composants headless) pour des interfaces accessibles et composables
- Framer Motion pour des micro-animations et des transitions physiquement réalistes
- L’éditeur de texte enrichi TipTap (13 extensions) pour la rédaction de contenu
- Recharts pour les tableaux de bord de visualisation de données
- DnD Kit pour les interactions de glisser-déposer du Kanban
- React PDF Renderer pour la génération de PDF côté serveur (exports de l’Executive Summary et du Pitch Deck)
Indicateurs de culture d’ingénierie
- Développement guidé par l’audit — 9 audits complets de modules et 9 rapports correctifs — chaque module est revu pour la sécurité, l’intégrité des données et la performance
- Méthodologie zéro régression — Unification de deux schémas de base de données (plus de 11 fichiers refactorisés) sans aucune rupture d’API
- Sécurité en profondeur — Validation à plusieurs niveaux sur chaque mutation. Sécurité des prompts. Masquage des données personnelles. Templates protégés contre le XSS
- Usage de l’IA maîtrisé en coûts — Des seuils de couverture évitent les inférences inutiles. Limites de tokens ajustées par point d’accès. Température calibrée par cas d’usage
- Internationalisation — Prise en charge de 9 langues avec des consignes de langue de sortie imposées au LLM. Modèles d’e-mails multilingues
- Documentation as code — 17 rapports techniques tenus à jour à côté du code
Vous lancez une startup ?
Nous construisons votre MVP et restons à vos côtés, de la validation de l’idée à la levée de fonds.
