Ce que le local règle vraiment
Les annonces d’août de Liquid AI sur LFM2.5-2.6B et sa variante multimodale, ainsi que la présentation de Muse Glimmer sur le blog Hugging Face, illustrent des possibilités d’exécution locale. Ce sont des descriptions de produits, pas des évaluations indépendantes de leur sûreté dans une entreprise.
Le local peut réduire certains transferts, améliorer la latence ou permettre un usage sans connexion permanente. Ces bénéfices dépendent de l’application complète : un modèle exécuté sur le poste peut encore être entouré de fonctions qui communiquent avec des services distants.
Le lieu d’exécution ne définit toutefois ni les données accessibles ni les actions autorisées. Un agent qui lit le courrier, ouvre un navigateur ou écrit dans un dossier d’entreprise exige des règles de journalisation et d’arrêt, qu’il tourne sur un portable ou derrière une API.
Le choix entre IA locale et cloud porte notamment sur les données, les coûts et l’exploitation. La maîtrise des actions de l’agent ajoute un autre ensemble de contraintes.
L’injection de prompt ne s’arrête pas à la frontière du cloud
Le référentiel OWASP LLM01:2025 décrit l’injection de prompt : un contenu peut infléchir le comportement du modèle lorsque celui-ci ne distingue pas correctement les instructions autorisées des données non fiables. Les mesures proposées réduisent le risque sans garantir l’élimination de tous les cas. Leur efficacité doit être testée sur le système déployé, avec ses documents, ses outils et ses permissions.
Cette faille ne dépend pas du lieu d’hébergement. Un document interne, une page web, un courriel ou une image peuvent porter une consigne. Si le système suit cette consigne et dispose de droits trop larges, il peut déclencher une action locale dommageable. Ce n’est pas automatique : le résultat dépend du modèle, des outils et des contrôles. Une frontière réseau ne suffit donc pas à établir la confiance dans les contenus lus.
Les techniques de RAG ou de fine-tuning, souvent présentées comme des remèdes, ne suppriment pas cette classe de risque. Elles peuvent la réduire dans certains cas. Les prendre pour une clôture serait une erreur de conception.
Le mandat avant le modèle
La question utile pour une PME n’est donc plus seulement « on-premise ou API ? ». Elle devient : que l’agent a-t-il le droit de faire, avec quelles preuves, jusqu’où, et qui peut couper.
Un modèle compact bien choisi peut rester local pour la classification, la recherche interne ou l’assistance à la rédaction. Dès qu’il enchaîne des outils — messagerie, fichiers, navigateur, tickets — il faut les mêmes contrôles que pour un compte à privilèges : moindre privilège, journal, révocation, jeu d’essai, responsabilité humaine.
Un agent local peut ainsi apporter une maîtrise supplémentaire sur l’hébergement et certains flux, sans être plus sûr pour toutes les actions. Pour pouvoir lui déléguer du travail, l’entreprise doit limiter ses droits, tester les situations trompeuses et conserver une possibilité de reprise. La proximité du matériel aide dans certains cas ; elle ne remplace pas ces contrôles.