L'offre est une centrale d'intelligence souveraine « 3-en-1 » : une infrastructure d'IA installée chez le
client, un contrat de maintenance qui en assure la vie (matériel, sécurité, mises à jour des modèles), et des agents
métiers qui automatisent des processus réels. C'est la déclinaison concrète du niveau 3 « serveur dédié »
de notre grille des 3 niveaux de souveraineté, et elle épouse exactement le partage ABAXINFO × AXION : Eric porte
l'infrastructure et l'exploitation, AXION porte les applications et les agents.
Le socle technique est solide. Deux serveurs séparés - un moteur d'inférence sans état, un serveur
applicatif qui porte les données - pour qu'un traitement lourd ne ralentisse jamais le chat des utilisateurs. Aucun port
ouvert sur le pare-feu du client. Et une gouvernance documentaire qui traite ce qui fait réellement échouer les projets de
ce type : la pollution de la base de connaissance et les réponses tirées de procédures périmées.
Deux points restent à cadrer avant de pouvoir chiffrer. Le premier est un alignement : l'architecture doit
porter les trois niveaux d'accès déjà décidés le 10 juillet (équipe, comptabilité, privé) et le
coffre-fort - aujourd'hui la recherche filtre sur la validité du document, pas sur les droits de celui qui pose la question.
Le second est une hypothèse à valider : « 3 à 5 utilisateurs simultanés » est un point de départ raisonnable, à mesurer au
banc en août puis à ajuster client par client.
Le choix matériel mérite d'être élargi plutôt que tranché : notre propre définition du niveau 3 englobe
l'achat sur site, le housing et le dédié loué. Le loué supprime le CAPEX, première objection d'une PME, et
transfère le risque d'obsolescence. Enfin, l'économie de l'offre est proposée en section 10 sous forme
d'ordres de grandeur - faits pour être contredits.
Contexte et promesse - à quoi sert cette offre
Une PME romande de 10 à 50 personnes qui veut utiliser l'IA a aujourd'hui trois options, et une seule qui règle vraiment la question de ses données. C'est la grille des 3 niveaux de souveraineté qui structure tout notre discours, et l'offre décrite ici en est le troisième niveau.
| Niveau | Où vivent les données | Ce que ça vaut |
|---|---|---|
| 1 · Cloud frontière | Chez un fournisseur américain | Intelligence maximale, zéro investissement, mais les données sortent et la dépendance est totale |
| 2 · Open source hébergé | Chez un hébergeur souverain, loué | Juridiction choisie, réversibilité, mais un tiers héberge toujours |
| 3 · Serveur dédié (cette offre) | Chez le client, ou sur un serveur dédié qui lui est réservé | Les données ne quittent pas l'entreprise. Fonctionne même sans internet. Investissement et exploitation à assumer - c'est là que nous intervenons |
La difficulté du niveau 3 n'est pas technique, elle est opérationnelle : une PME n'a ni l'envie ni les compétences d'exploiter un serveur d'IA. D'où une offre qui ne vend pas une machine mais un service complet, en trois volets indissociables.
- Serveur d'inférence dédié sur site
- Serveur applicatif et base de connaissance
- Réseau cloisonné, sauvegarde, reprise
- Zéro donnée dans le cloud public
- Supervision et correctifs de sécurité
- Mise à jour des modèles, sans dérive des réponses
- Sauvegarde et test de restauration
- Point d'entrée unique pour les utilisateurs
- Chat interne sur les documents de l'entreprise
- Automatisation de processus (factures, RH, appels d'offres)
- Connexion aux outils déjà en place
- Nouveaux cas d'usage au fil de l'eau
Qui fait quoi
| Acteur | Périmètre |
|---|---|
| Fournisseur matériel | Livraison et installation physique des machines. Partenariat Computer Shop déjà engagé. |
| ABAXINFO (Eric) | Déploiement de l'infrastructure, supervision, maintenance système, mises à jour des modèles. C'est le métier historique, et le visage de confiance côté client. |
| AXION (Seb, Djemel) | Applications métiers, base de connaissance, orchestration des agents, intégration du RAG. La couche qui transforme une machine qui tourne en valeur métier. |
Architecture matérielle et arbitrage économique
Le poste matériel décide du prix d'entrée, donc de l'accessibilité de l'offre pour une PME. Deux familles de solutions s'opposent, avec un écart de coût de l'ordre du double.
| Option | Ordre de prix | Lecture |
|---|---|---|
| Serveur Linux bi-GPU cartes professionnelles | 12 000 - 15 000 € | Puissance et écosystème mature pour l'inférence, mais surdimensionné financièrement pour l'amorçage chez une PME. |
| Station à mémoire unifiée type Mac Studio M2 Ultra 192 Go, reconditionné | 5 500 - 6 500 € | Les 192 Go de mémoire unifiée permettent de faire tourner des modèles de 70 milliards de paramètres quantifiés, en gardant de la réserve pour le contexte de plusieurs sessions. Durabilité annoncée de 4 à 6 ans. |
Ce qui devrait être écrit dans l'offre, ce n'est donc pas un modèle de machine mais une enveloppe de performance : taille de modèle supportée, nombre de sessions concurrentes, temps de réponse. Le matériel devient une variable d'ajustement commercial, pas un pari technique.
Le moteur d'inférence. Les deux moteurs couramment cités (Ollama, vLLM) n'ont pas les mêmes capacités de traitement par lots selon la plateforme. Plutôt que d'en débattre, en faire une mesure au banc : quel moteur tient réellement 3 à 5 sessions concurrentes sur la machine retenue, et avec quel temps de première réponse sur des requêtes à contexte long ? C'est le même banc que la démonstration du 5 novembre - une pierre, deux coups.
Topologie réseau et sécurité
Le principe directeur : permettre une maintenance à distance transparente sans jamais ouvrir un port sur le pare-feu du client, et exposer l'application aux collaborateurs distants sans exposer le réseau local. Les deux flux sont strictement séparés.
- Accès par navigateur, en HTTPS
- Aucune installation sur le poste
| Accès | Mécanisme | Pourquoi ce choix | Coût |
|---|---|---|---|
| Maintenance Eric, AXION | Tailscale, réseau maillé chiffré de bout en bout | Agent installé sur les deux serveurs, aucun port à ouvrir. Insensible aux changements d'adresse publique du client. | Gratuit jusqu'à ~6 administrateurs |
| Collaborateurs télétravail | Cloudflare Tunnel | L'application web est jointe par un tunnel sortant. L'API du serveur IA et les bases restent invisibles depuis internet. | Gratuit jusqu'à 50 utilisateurs |
Architecture logique - pourquoi deux serveurs et pas un
C'est le choix de conception le plus structurant. La charge est répartie sur deux serveurs physiques et un NAS, pour une raison précise : éviter qu'un traitement applicatif lourd ne ralentisse la génération du modèle, et inversement. Si l'indexation nocturne de 4 000 documents tourne sur la même machine que le chat, les utilisateurs le sentent immédiatement.
- Inférence : exécution locale du modèle de langage
- Passerelle et priorisation : gestion de la file d'attente et de la qualité de service
- Ne contient rien : on peut le remplacer sans perte de données
- Interface : le chat interne et les applications métiers
- Base de données et vectorisation : la base de connaissance permanente
- Automatisations : routines planifiées, connecteurs, serveurs d'outils
- Accès aux fichiers : montage du partage réseau existant du client
- Sauvegarde quotidienne de la base (données et vectorisation)
- Sauvegarde des configurations et des scripts d'agents
Le dimensionnement devient indépendant. On peut augmenter la puissance d'inférence sans toucher à l'applicatif, ou l'inverse - donc adapter l'offre à la taille du client sans repenser l'architecture.
Agents, routines et flux métiers
Trois modes d'utilisation cohabitent, du plus direct au plus autonome. C'est ce qui différencie une offre d'un simple « ChatGPT interne » : la machine ne se contente pas de répondre, elle travaille.
Limite à connaître : la priorisation gère la contention, elle ne crée pas de puissance de calcul. Elle évite qu'un utilisateur soit bloqué derrière un traitement long, mais elle ne rend pas la machine plus rapide. C'est directement lié au point 2 de la section 8.
Le RAG d'entreprise - la base de connaissance
Le RAG, c'est ce qui permet à l'IA de répondre sur les documents de l'entreprise et non sur des généralités. C'est aussi la partie où les projets de ce type échouent le plus souvent, pour deux raisons toujours les mêmes : la base se pollue, et l'IA finit par répondre à partir de procédures périmées. L'architecture les traite de front.
A. Deux régimes documentaires, à ne pas confondre
| Critère | Document éphémère | Vault permanent |
|---|---|---|
| Usage | Analyse rapide d'un PDF déposé dans le chat par un utilisateur | Mémoire collective : RH, procédures, tarifs, contrats |
| Traitement | Traité en mémoire, dans la session de conversation | Découpé, vectorisé et stocké dans la base |
| Persistance | Supprimé à la fermeture de la session | Conservé pour toutes les recherches ultérieures |
B. Gouvernance - empêcher la pollution
- File d'attente avant indexation. Un document déposé par un utilisateur n'entre jamais directement dans la base permanente : il passe par une zone tampon.
- Validation humaine. Un responsable valide le document depuis son tableau de bord avant qu'il ne soit indexé pour tout le monde.
- Isolation par métadonnées. Chaque fragment vectorisé porte son origine (document, auteur, département, statut de validation). En cas d'erreur, on purge l'intégralité d'un document fautif en une opération, sans toucher au reste.
C. Versionnement - ne jamais répondre depuis une procédure périmée
Chaque document porte un indicateur actif / archivé. Quand la version 2026 d'une procédure est déposée, la version 2024 bascule automatiquement en archivé, et la recherche ne consulte que les documents actifs. L'historique reste consultable pour l'audit, mais l'IA ne s'en sert plus pour répondre.
D. L'ingestion initiale - le poste le plus sous-estimé
- Nettoyage préalable par le client. Tri des doublons et des fichiers obsolètes avant le premier import. Une base de connaissance construite sur un partage réseau en désordre produira des réponses en désordre.
- Découpage structurel. Respecter la structure des documents (titres, chapitres, sections) plutôt que de découper aveuglément tous les N caractères. C'est ce qui fait la différence entre une réponse pertinente et une réponse tronquée.
- Étiquetage automatique par arborescence. Le script d'import transforme le chemin des dossiers en métadonnées :
/Comptabilite/2025/devient un tag de département. Gratuit, et immédiatement exploitable pour filtrer.
Stack technique
L'ensemble repose sur des briques open source, sans coût de licence. Le coût réel n'est pas la licence, c'est l'exploitation - c'est-à-dire le temps d'Eric. Ce point conditionne directement la marge du contrat de maintenance, et il est repris en section 9.
| Brique | Solution | Rôle | Licence |
|---|---|---|---|
| Moteur d'inférence | Ollama ou vLLM (à départager au banc) | Exécution locale du modèle de langage | Open source |
| Passerelle API | LiteLLM | Clés d'accès, quotas, priorisation des requêtes | Open source |
| Base et vectorisation | PostgreSQL + pgvector (via Supabase ou seul, voir §9) | Données applicatives et base de connaissance | Open source |
| Interface et applications | Next.js | Chat interne et applications métiers | Open source |
| Orchestration | n8n, routines Node.js / Python | Automatisations et intégrations | Open source |
| Accès maintenance | Tailscale | VPN maillé pour la supervision à distance | Gratuit < 6 admins |
| Accès distant | Cloudflare Tunnel | Exposition web chiffrée pour les collaborateurs | Gratuit < 50 users |
Les deux points à cadrer avant de vendre
Deux points demandent une décision avant de pouvoir chiffrer. Le premier est un alignement : l'architecture doit porter un modèle d'accès déjà décidé en atelier. Le second est une hypothèse de dimensionnement à valider, qui se réglera au banc puis client par client.
La matière est déjà là : chaque fragment vectorisé porte son département et son auteur. Ce qui manque est la marche suivante. Aujourd'hui, la recherche ne filtre que sur la validité du document (actif / archivé), pas sur le périmètre de l'utilisateur. En l'état, un collaborateur peut faire ressortir un document RH ou comptable en posant simplement la question dans le chat.
Le modèle à appliquer est déjà décidé. L'atelier du 10 juillet (D-07) a retenu trois niveaux d'accès sur serveur souverain - équipe, comptabilité, privé - et un coffre-fort pour les données les plus sensibles. Il ne s'agit donc pas d'ouvrir un débat, mais de reporter ces trois niveaux dans l'architecture documentaire.
Traduction concrète : le filtre d'autorisation s'applique à la recherche et pas seulement à l'affichage, et le coffre-fort se traduit par un espace non indexé par défaut - un document qu'on ne veut pas voir ressortir ne doit pas être vectorisé « au cas où ». Peu de travail si c'est prévu dès le départ, très coûteux à rattraper ensuite.
Pourquoi c'est éliminatoire commercialement : la cible prioritaire est composée de fiduciaires et de cabinets médicaux. Le défaut ne se voit pas en test - il se voit le jour où quelqu'un demande combien gagne un collègue.
Elle demande deux précisions avant de porter un prix. D'abord son sens : simultané veut dire cinq personnes qui ont un onglet ouvert, ou cinq générations en parallèle ? Sur un modèle de 70 milliards de paramètres quantifié, ce n'est pas le même monde. Ensuite son comportement sous charge, sachant que la priorisation gère la contention mais ne crée pas de puissance de calcul.
Ce n'est pas une faiblesse de l'architecture, c'est un travail de calibrage, en deux temps :
1. Au banc, en août. Mesurer ce que la machine tient réellement : temps de première réponse, débit par session, nombre de sessions concurrentes avant dégradation sensible. Le cas à mesurer n'est pas le chat à vide mais la requête documentaire à contexte long, où l'on injecte des extraits - c'est là que le temps de première réponse se dégrade.
2. Client par client, ensuite. Le bon chiffre n'est pas universel : il dépend du nombre d'utilisateurs réels, de leur métier et de la part d'automatisation nocturne. L'hypothèse devient alors une grille de dimensionnement (section 10), et le dimensionnement devient un argument de conseil plutôt qu'une promesse figée.
À séquencer - réel, mais qui peut attendre la v1
L'économie de l'offre
Une architecture n'est pas une offre. Tant que le récurrent n'est pas chiffré, on ne sait pas si le contrat de maintenance est rentable - et c'est Eric qui porte l'astreinte. Ce qui suit est une proposition de structure avec des ordres de grandeur, faits pour être contredits par la connaissance du marché romand. Montants en CHF ; la logique compte davantage que les chiffres.
| Installation | Contenu | Ordre de grandeur (hypothèse) |
|---|---|---|
| Matériel | Serveur d'inférence + serveur applicatif. Acheté par le client, ou intégré au récurrent si l'on retient le dédié loué. | 6 000 - 9 000 ou lissé |
| Mise en service | Installation, réseau (VPN et tunnel), sécurisation, sauvegarde et test de restauration. | 3 000 - 5 000 |
| Ingestion initiale | Tri avec le client, découpage, étiquetage, premiers contrôles de pertinence. Le poste le plus sous-estimé : c'est là que la qualité des réponses se joue, et il dépend de l'état des dossiers du client. | 2 000 - 6 000 selon volume |
| Premiers agents métiers | Deux ou trois cas d'usage livrés, choisis avec le client. C'est ce qui rend l'installation utile dès le premier mois. | 4 000 - 10 000 |
| Total installation | Un projet, pas une vente de matériel. | 15 000 - 30 000 |
| Récurrent mensuel (IAGérance) | Ce qui est inclus | Ordre de grandeur (hypothèse) |
|---|---|---|
| Socle | Supervision, correctifs de sécurité, sauvegarde et test de restauration périodique, veille sur les modèles. | 600 - 1 200 / mois |
| Cycle de vie des modèles | Mise à jour avec jeu de non-régression rejoué. C'est la promesse différenciante : on ne met pas seulement à jour, on garantit que les réponses ne dérivent pas. | inclus dans le socle |
| Support utilisateurs | Point d'entrée unique, accompagnement des usages. À doser : c'est le poste qui dérape si le périmètre n'est pas écrit. | 300 - 800 / mois |
| Évolutions incluses | Un forfait d'heures mensuel pour faire vivre les agents (ex. 4 à 8 h). Au-delà, grille horaire, sur le modèle de la réponse Trajets. | selon forfait |
| Total récurrent | C'est lui qui rend le modèle viable, pas l'installation. | 1 000 - 2 500 / mois |
2. Le périmètre de l'astreinte se définit avant le prix, pas après. Horaires, délai de reprise, qui décroche. Sans ça, le récurrent est un pari sur le comportement du client. C'est Eric qui la porte : il fixe, on chiffre ensuite.
3. Ce qui est exclu doit être écrit aussi clairement que ce qui est inclus. Reprise de données hors périmètre, nouveaux cas d'usage, formation de nouveaux arrivants, changement de modèle demandé par le client. Une grille hors forfait existe déjà sur la réponse Trajets - la réutiliser plutôt que d'en inventer une.
Grille de dimensionnement - ce qui remplace le chiffre unique
| Profil | Charge attendue | À valider au banc |
|---|---|---|
| Petite - 10 à 20 personnes | 2 à 3 sessions actives en pointe, automatisation nocturne légère | Modèle intermédiaire probablement suffisant |
| Moyenne - 20 à 35 personnes | 3 à 5 sessions actives, automatisation quotidienne | Cible de référence - à mesurer en priorité |
| Haute - 35 à 50 personnes | 5 à 8 sessions actives, traitements de nuit réguliers | Second serveur d'inférence, ou modèle plus petit |
Le seuil de rentabilité est la question qu'on pose en dernier mais qu'il faut résoudre en premier : à partir de combien de clients l'astreinte et le suivi des modèles deviennent-ils soutenables sans saturer Eric ? Tant que ce nombre n'est pas posé, on ne sait pas si l'on construit une offre ou un métier à perte. C'est aussi ce qui détermine le rythme de vente visé après le 5 novembre, à rapprocher de l'objectif de 5 à 10 clients par an.
Or le témoignage client est aujourd'hui l'un des trois blocs non confirmés de la soirée, et l'atelier du 24 juillet (D-08) a rappelé que la crédibilité de l'offre repose sur un partenaire, un lieu et un client référent. Le même client résout les deux problèmes : il valide l'architecture sur le terrain avant novembre, et il monte sur scène pour en parler.
Cela impose un calendrier : pour témoigner le 5 novembre, le pilote doit tourner en septembre-octobre, donc être contractualisé fin août.
Décisions à trancher - journal ouvert
Numérotation D-A## propre à ce dossier, pour ne pas entrer en collision avec les décisions d'atelier.
Ce tableau est la partie vivante du document : il se complète et se tranche d'atelier en atelier.
| ID | Décision à prendre | Enjeu | Statut |
|---|---|---|---|
| D-A01 | Reporter les trois niveaux d'accès dans le RAG : dès la v1 ? | Le modèle est déjà décidé le 10/07 (D-07). Il s'agit de l'implémenter, pas d'en débattre. | Ouvert |
| D-A02 | Valider l'hypothèse « 3 à 5 simultanés » au banc, puis en faire une grille par taille de client. | Point de départ à mesurer, pas à figer. Conditionne le prix. | Ouvert |
| D-A03 | Matériel : réintègre-t-on le dédié loué ? Achat ou location par défaut ? | Lève l'objection CAPEX et le risque d'obsolescence. | Ouvert |
| D-A04 | Stack complète ou PostgreSQL + pgvector seul ? | Surface à maintenir = marge du contrat. | Ouvert |
| D-A05 | Périmètre de l'astreinte : horaires, délai de reprise, qui décroche. | Eric la porte. À définir avant de vendre. | Ouvert |
| D-A06 | Économie : prix d'installation, récurrent, périmètre, sortie. | Sans ça, pas d'offre. Cible : fin août. | Ouvert |
| D-A07 | Réversibilité : que possède et qu'emporte le client ? | Différenciateur, ou objection offerte au concurrent. | Ouvert |
| D-A08 | Client pilote : le client finance est-il le premier terrain, et le témoin du 5 novembre ? | Résout deux problèmes d'un coup. Contractualisation fin août. | Ouvert |
| D-A09 | Non-régression sur les mises à jour de modèle : jeu de test, qui le maintient ? | Cœur de la promesse IAGérance. | Ouvert |
| D-A10 | Contrat de sous-traitance et journalisation des accès. | Critère d'achat pour fiduciaires et santé. | Ouvert |
Comment ce document évolue
Ce dossier est volontairement séparé des supports d'atelier : un support est jetable, celui-ci ne l'est pas. Il a vocation à devenir la spécification de l'offre vendue en sortie de l'événement.
- À chaque atelier qui touche à l'offre ou à l'IA locale : les décisions tranchées passent de « Ouvert » à la date et au sens de la décision, dans le tableau de la section 11. Rien ne se supprime - un arbitrage abandonné se note comme tel.
- Fin août : les trois décisions prioritaires (D-A01, D-A02, D-A08) doivent être fermées, sans quoi le pilote ne peut pas tourner en septembre-octobre, et le témoignage du 5 novembre tombe.
- Septembre-octobre : le pilote alimente le document en retours de terrain - les mesures réelles remplacent les hypothèses, en particulier sur la charge et le dimensionnement.
- Après le 5 novembre : la version qui en sort devient la base de la proposition commerciale type, réutilisable de client en client.
Statut des affirmations. Tout ce qui est présenté comme acté renvoie à une décision d'atelier tracée. Les points techniques de la section 2 (moteur d'inférence, tenue en charge) sont formulés comme des mesures à faire au banc, pas comme des conclusions. Les montants de la section 10 sont des ordres de grandeur proposés, destinés à être corrigés.