Le discours commercial est bien rodé : plus le modèle est gros, plus il est intelligent, plus il sera juste sur vos données. Donc prenez le plus gros, et l'abonnement entreprise qui va avec. Vos données partent chez l'éditeur, mais c'est le prix de la qualité.
Nous avons fait l'inverse sur un pilote en cours : un modèle ouvert de taille moyenne, qui tourne sur une machine que nous administrons, branché sur Odoo. Non par idéologie, mais parce que la question « quel stock pour ce produit » n'a rien à voir avec la question « rédige-moi un contrat ». Voici ce que nous avons constaté.
Un gros modèle devine. C'est son métier.
Posez à un grand modèle d'éditeur une question sur votre ERP sans lui donner d'outil, et il répond quand même. Il complète avec un chiffre plausible, une référence qui ressemble à la vôtre, un délai raisonnable. C'est exactement ce pour quoi il a été entraîné : produire la suite la plus probable. Sur un ERP, la suite la plus probable est presque toujours fausse, parce que votre stock n'est pas probable, il est exact.
Donnez-lui un serveur MCP générique, celui qu'Odoo 20 livre désormais, et il doit comprendre le schéma d'Odoo : quel modèle, quel champ, quelle jointure. Un gros modèle y arrive souvent. Mais il y arrive en plusieurs appels, en se trompant parfois de champ, et vous payez chaque appel en crédits.
Un petit modèle bien outillé n'a rien à deviner
Notre choix d'architecture, écrit dans une décision datée, a été de construire des outils par intention, pas par objet Odoo. Le modèle n'appelle pas « rechercher dans res.partner puis dans sale.order ». Il appelle « le dossier de ce client », et l'outil lui rend le dossier : coordonnées, devis en cours, dernières factures, machines. Le modèle n'a plus qu'à rédiger. Il n'a rien à savoir d'Odoo.
Résultat : un modèle ouvert de 27 milliards de paramètres rédige les réponses, et un modèle de 9 milliards classe chaque message entrant. Les deux tournent sur une machine que nous administrons. Aucune donnée du pilote ne transite par un fournisseur américain pour répondre à une question de stock. Le détail du routage est sur IA souveraine pour PME.
La vitesse vient de la même idée. Les clients et les références sont cherchés dans un index local, avec tolérance aux fautes et aux pluriels : 31 millisecondes mesurées en direct sur une recherche au pluriel. Les prix et le stock, eux, sont toujours relus en direct dans Odoo, jamais depuis une copie. L'index sert à trouver, Odoo sert à répondre.
Ce que ça coûte : une carte graphique, pas un compteur
Le second effet d'un petit modèle bien outillé, c'est l'argent. Il tourne sur un ordinateur équipé d'une bonne carte graphique, et chaque question coûte zéro euro. En face, Odoo 20 facture ses fonctions d'IA 1 € le crédit sans publier combien en consomme une question, et les assistants du marché se paient de 20 à 25 $ par siège et par mois, qu'on s'en serve ou non.
Pour commencer, une carte de joueur de 8 Go suffit : notre modèle de 9 milliards y tourne en permanence et classe chaque message. Pour rédiger des réponses justes sur un ERP, on vise 24 Go, le niveau du modèle de 27 milliards. Ordre de grandeur : 2 000 à 2 500 € de matériel une fois, administré à distance. Beaucoup de dirigeants ont déjà la machine sans le savoir. Le calcul détaillé : crédits, abonnements ou une machine à vous.
Et si un modèle ouvert ne parle pas assez votre métier, il s'entraîne sur ce même matériel. Nous avons outillé un fine-tuning (un adaptateur LoRA) sur une carte de 8 Go pour le jury de chant de kiaraoke.fr. On ne commence jamais par là, mais on s'y colle quand les erreurs mesurées le justifient.
Ce que le petit modèle ne fait pas
Soyons honnêtes, parce que c'est le seul moyen que vous nous croyiez sur le reste. Sur un usage ouvert, rédiger une proposition commerciale de trois pages, analyser un contrat, raisonner sur une situation inédite, les grands modèles d'éditeurs restent devant. Nous les utilisons pour ça, et nous les routons vers les tâches où ils apportent quelque chose.
Le petit modèle a aussi ses limites sur l'ERP : il est moins bon pour comprendre une question très mal formulée, et il faut lui donner des outils bien découpés. C'est du travail d'architecture, pas de prompt. Sur le pilote, deux clients homonymes ont été départagés par la ville parce que l'outil renvoyait la ville, pas parce que le modèle était malin.
Dernier garde-fou, indispensable avec n'importe quelle taille de modèle : un chiffre que l'agent cite et qu'aucun outil n'a rendu est repéré par du code, et la réponse est bloquée. Sur le pilote, chaque chiffre d'affaires par vendeur a été recoupé au centime dans Odoo avant d'ouvrir l'outil à l'équipe.
Cette architecture est celle de notre serveur MCP pour Odoo. Pour voir ce qu'un agent ainsi outillé peut et ne peut pas faire, lisez l'agent qui ne peut pas toucher aux prix. Et si vous voulez qu'on regarde ensemble quelles questions valent un outil chez vous, soixante minutes sans engagement : prenez rendez-vous.