01
Interface métier
Écran simple et intuitif : mails, clients, produits, SAV, agenda. Facilite le quotidien, sans changer vos habitudes.
Architecture technique
Un modèle IA local, branché sur votre SI, pas à la place.
L’architecture est volontairement simple : un serveur chez vous, un socle data, un LLM léger, des modules métier activables, une interface du quotidien.
Couches
De l’utilisateur jusqu’au serveur : chaque couche a un rôle unique. Rien n’est délégué à un cloud d’inférence.
02
Modules IA activables
Chaque module est un MVP fonctionnel. Activation progressive selon vos règles et votre métier.
03
Socle data + LLM léger
Le modèle combine les avantages d’une base de données et d’un LLM modulaire. Index, historique et règles restent chez vous.
04
Connecteurs vers votre SI
Lecture et assistance sur vos outils existants (ERP, CRM, messagerie, fichiers). Rien n’est remplacé.
05
Serveur interne, capacité adaptable
Le modèle tourne on-premise, dans votre SI, sur un serveur dimensionné selon vos besoins.
- Vos données ne sortent pas : exécution interne, maîtrise conservée, conformité RGPD.
Principes
On-premise
Le modèle s’installe dans votre SI. Il tourne sur un serveur interne, avec une capacité adaptée à votre volume et à votre rythme d’activation.
Data + LLM
Nous combinons un socle de données (index, historique, règles) et un LLM léger, modulaire. L’usage reste transparent pour les équipes.
Sans remplacer le SI
Les connecteurs s’appuient sur vos outils actuels. L’interface assiste les démarches quotidiennes : elle ne force pas un nouvel ERP.
Modules progressifs
Mails, clients, produits, SAV, agenda : chaque brique est un MVP validé sur vos échantillons, puis intégré et étendu selon vos règles.
Flux type
1
Demande métier
Un collaborateur agit dans l’interface (relance, SAV, mail, rendez-vous).
2
Contexte local
Le socle data lit uniquement ce qui est nécessaire dans vos bases et fichiers.
3
Assistance IA
Le LLM léger propose, rédige ou oriente, selon vos règles métier.
4
Action maîtrisée
Vous validez. Rien n’est poussé dans le SI sans contrôle.
Après validation du MVP sur des échantillons, nos équipes intègrent le modèle dans votre système d’information, selon votre corps de métier. La capacité du serveur s’ajuste ensuite à la montée en charge.
Garde-fous
Assistance, pas autonomie.
L’IA propose, vous validez
Brouillons, relances, créneaux : rien de sensible ne part ou ne s’écrit dans le SI sans feu vert métier.
Lecture maîtrisée, pas un nouveau SI
Le modèle s’appuie sur vos bases et vos fichiers utiles. Vos outils restent la référence.
Règles et activation progressive
Un module à la fois, selon vos process. Le modèle évolue avec vos règles, porté par une équipe resserrée.
Prérequis du MVP
Ce dont nous avons besoin pour démarrer.
Un process ciblé
SAV, relance, mails, agenda ou un autre rituel quotidien — un seul, pour le premier MVP.
Un référent métier
Quelqu’un qui connaît la vraie façon de travailler, pas seulement le schéma d’architecture.
Des échantillons
Tickets, mails, fiches produit, extraits de planning : de quoi valider sur vos données, pas sur un jeu public.
Un serveur dans votre SI
On-premise, capacité adaptable. Le dimensionnement se cale après le cadrage, pas avant d’avoir vu le process.
LLM locaux
Comparer les modèles, puis choisir la taille qui tient dans votre SI.
Un LLM cloud sort vos données. Un modèle de 70 milliards de paramètres exige une baie. Pour le SAV, la relance, le mail et l’agenda, un LLM léger + un socle data local est en général plus juste : moins d’infra, plus de maîtrise, activation progressive. Nous n’imposons pas une famille unique : le moteur s’adapte à votre serveur et à votre métier.
| Famille | Taille type | Infra locale | Intérêt | Limite |
|---|---|---|---|---|
| LLM cloud (GPT, Claude…) | Fermé | Aucun serveur chez vous | Qualité brute, zéro infra | Données et tokens hors de votre SI, coût à l’usage, dépendance |
| Très grands modèles locaux | 70B à 600B+ | Multi-GPU / baie dédiée | Proche du frontier, raisonnement long | Lourd, cher, lent à faire évoluer pour un SAV ou une relance |
| Llama 4 Scout | MoE ~17B actifs | 2× GPU 24 Go (ordre) | Contexte extrême, écosystème Meta | Licence communautaire, footprint encore élevé |
| Mistral / MinistralAdapté à un déploiement SQL STATE | 3B à 14B+ | 1 GPU 8–24 Go | Licence claire, éditeur UE, bon français, inférence rapide | Moins large que les familles asiatiques sur certains benchmarks |
| Qwen 3.x (9B–27B)Adapté à un déploiement SQL STATE | 9B à 27B | 1 GPU 8–24 Go | Excellent rapport qualité / VRAM, Apache 2.0, contextes longs | Éditeur hors UE : à cadrer en banque / assurance |
| Gemma 4 (12B–31B)Adapté à un déploiement SQL STATE | 12B à 31B | 1 GPU 8–24 Go | Dense, bon quotidien, tient sur une carte 24 Go | Conditions d’usage Google à relire pour un SI régulé |
Cloud
Simple à démarrer, mais tokens, fuite de contexte et perte de maîtrise. Peu compatible avec un SI banque / assurance.
Gros modèle local
Puissant, mais coûteux à héberger 24/7. Souvent disproportionné pour des process métier répétitifs.
LLM léger + data
Notre choix par défaut : inférence interne, socle sur vos bases, capacité de serveur adaptable, modules activés un par un.
Ordres de grandeur 2026 : un modèle 8–14B tient sur un GPU 8–16 Go ; un 27–31B tient en général sur une carte 24 Go en quantification 4 bits. Les MoE géants (centaines de milliards de paramètres) restent du domaine du cluster. Le bon modèle est celui qui répond à vos process — pas celui qui gagne un classement public.
Discuter d’un déploiement