IA locale ou API, que choisir pour ton assistant ?

Avant de construire un assistant IA, il faut choisir le moteur qui écrira ses réponses. Deux voies s'ouvrent : appeler une IA chez un fournisseur, par API, ou installer un modèle sur ta propre machine. Chaque voie a de vrais avantages et de vrais compromis. Voici comment trancher, avec l'exemple concret de Flopia, l'assistante de Flopix, qui a choisi la seconde.

Les deux voies en une phrase

• L'API : ton site envoie la question à un fournisseur d'IA, qui renvoie la réponse. Tu ne gères aucune machine.
• Le local : un modèle ouvert tourne sur ton ordinateur ou ton serveur, piloté par un logiciel comme Ollama. Tout reste chez toi.

Le reste de l'assistant (consignes, documentation, garde-fous, tests) est le même dans les deux cas.

Ce que l'API apporte

La qualité

Les fournisseurs proposent des modèles très grands. Ils comprennent les nuances, suivent des consignes longues, raisonnent sur des cas complexes. Pour un assistant qui doit analyser un problème technique ou rédiger des réponses subtiles, c'est un vrai plus.

La vitesse

Les serveurs des fournisseurs sont équipés pour ça. Les réponses arrivent en général en quelques secondes, et plusieurs visiteurs peuvent écrire en même temps sans faire la queue.

La simplicité

Pas de machine à installer, à mettre à jour, à surveiller. Tu obtiens une clé, tu appelles le service, c'est tout.

Ce que l'API coûte

• Un coût à l'usage, qui dépend du volume de texte lu et écrit. Il suit ton trafic : un mois chargé coûte plus. Les grilles changent souvent, vérifie-les chez chaque fournisseur.
• Des données qui transitent : les conversations de tes visiteurs passent par le fournisseur. Lis ses conditions sur la conservation et l'usage de ces données, et mentionne-le dans ta politique de confidentialité.
• Une dépendance : le fournisseur peut modifier un modèle, en retirer un, changer ses conditions. Ton assistant peut changer de comportement sans que tu aies touché à rien.

Ce que le local apporte

La maîtrise des données

Les conversations ne quittent pas ton serveur. C'est l'argument retenu par Flopix pour Flopia : sur flopia.fr, il est expliqué que le modèle tourne sur les serveurs de Flopix, chez OVHcloud en France, et que les conversations ne partent pas chez un fournisseur d'IA étranger.

Un coût prévisible

Tu paies la machine, pas les questions. Que ton assistant réponde à dix ou à mille questions, la facture du serveur ne bouge pas.

La stabilité

La version du modèle ne change que si tu le décides. Un assistant qui fonctionne aujourd'hui fonctionnera pareil demain.

Ce que le local coûte

Le cas de Flopia est parlant. Elle tourne avec un modèle qwen3 4B en version « instruct », servi par Ollama, sur un serveur sans carte graphique. Les tests ont mis en évidence des contraintes très concrètes :

• La lecture prend du temps. Le modèle lit de l'ordre de 20 jetons (morceaux de mots) par seconde sur ce processeur. Chaque phrase de consigne et chaque extrait de documentation se paie en secondes d'attente.
• Une question à la fois. Le serveur traite les questions l'une après l'autre. L'espace de test de Flopia annonce de 10 à 60 secondes par réponse.
• Une petite fenêtre. Le contexte est réglé sur 4 096 jetons en tout : consignes, documentation, historique et réponse doivent y tenir.
• Un modèle moins obéissant. Un modèle de 4 milliards de paramètres suit moins bien les consignes qu'un grand modèle. Il faut des phrases courtes, des scénarios ciblés et des filtres dans le code.

Ces chiffres valent pour cette machine précise. Avec une carte graphique ou un serveur plus puissant, tout change, mais le coût de la machine aussi.

Les astuces qui rendent le local viable

L'équipe de Flopix a appris plusieurs choses en réglant Flopia :

• Garder les consignes générales identiques d'une question à l'autre. Le moteur peut alors les garder en mémoire au lieu de les relire, et la première réponse arrive bien plus vite.
• Préchauffer le modèle quand le visiteur ouvre la bulle, pas à chaque page visitée.
• Lire moins : peu d'extraits de documentation, courts et pertinents, plutôt que des pages entières.
• Répondre sans modèle quand c'est possible : les questions des boutons de suggestion ont des réponses rédigées à l'avance, affichées instantanément.
• Choisir la bonne variante : certains modèles existent en version qui « réfléchit » longuement avant de répondre. Sur un processeur, cette réflexion peut durer des minutes. Pour un assistant de site, la variante qui répond directement est la bonne.

Comment trancher

Réponds à ces questions, dans l'ordre :

1. Les conversations contiennent-elles des informations sensibles ? Si oui, le local, ou un fournisseur aux garanties claires et documentées.
2. Les questions sont-elles simples et répétitives ? Horaires, accès, conditions : un petit modèle bien réglé suffit. Analyses complexes : l'API.
3. Quel volume attends-tu ? Faible et irrégulier : l'API est souvent plus simple. Élevé et régulier : un serveur peut devenir intéressant, à condition d'accepter ses limites ou d'investir dans une machine adaptée.
4. Qui s'occupe de la machine ? Si personne, l'API t'enlève ce souci.
5. Combien de temps tes visiteurs accepteront-ils d'attendre ? Sur une bulle de site, quelques secondes, c'est confortable. Une minute, c'est long : il faudra l'annoncer et réduire au maximum ce que le modèle doit lire.

Le bon réflexe : séparer les réglages du moteur

Quel que soit ton choix, garde tes réglages (identité, règles, interdits, scénarios, documentation, tests) dans un endroit à part, indépendant du moteur. Le jour où tu changes de modèle ou de voie, tu repasses tes tests et tu ajustes, sans tout réécrire. Pour écrire ces réglages, lis comment écrire les consignes de son assistant IA, et pour le contexte général, mettre un chatbot IA sur son site.

La formation Créer son assistant IA consacre une leçon entière à ce choix, puis te guide dans tous les réglages, quel que soit le moteur retenu.