Petits modèles sur poste : quand la donnée ne sort pas

Un modèle qui tourne sur le poste de travail ne pose aucune question de transfert de données, parce qu'aucune donnée ne part. C'est une propriété structurelle, pas une garantie contractuelle.

La différence est considérable en discussion avec une direction juridique ou un responsable de la sécurité. Un traitement local ne demande ni analyse de transfert, ni clause de localisation, ni engagement de non-conservation. Il n'y a rien à encadrer.

Cette propriété ouvre des usages qui restaient bloqués : traiter un document contenant des données de santé, préparer une note à partir d'un dossier contentieux, résumer des échanges internes sensibles.

L'extraction, la classification, la reformulation et le résumé court sont traités à un niveau utilisable ; l'analyse complexe ne l'est pas. Cette frontière s'est déplacée mais elle existe toujours.

Les tâches structurées passent bien parce que la réponse attendue est courte et contrainte. Extraire une date, classer un document, anonymiser un texte, reformuler dans un registre donné : un modèle de quelques milliards de paramètres y suffit.

Le résumé court fonctionne aussi, à condition de ne pas dépasser quelques pages en entrée.

Ce qui ne passe pas : le raisonnement en plusieurs étapes, l'analyse de cohérence entre documents, la synthèse d'un dossier volumineux. Ces tâches demandent un modèle et une fenêtre que le poste de travail ne fournit pas.

La frontière se vérifie sur le jeu de tests, comme toujours, et elle se déplace à chaque génération, le raisonnement de l'écart se resserre sur les tâches structurées.

La performance dépend de la machine de chaque utilisateur, ce qui crée une hétérogénéité que les systèmes centralisés n'ont pas. C'est le principal obstacle au déploiement à grande échelle.

Un même traitement peut prendre quelques secondes sur un poste récent et une minute sur un poste de trois ans. L'expérience varie donc fortement d'un collaborateur à l'autre, sans que rien dans l'application ne l'explique.

S'y ajoute la question du déploiement : installer et mettre à jour un modèle sur plusieurs centaines de postes est un chantier d'administration classique, avec ses contraintes propres.

Et une limite plus subtile : les traces d'usage restent sur les postes, ce qui complique la journalisation centrale exigée par ailleurs. Il faut décider explicitement ce qui remonte, les métadonnées d'usage, pas le contenu, et le documenter.

Un modèle local pour tout ce qui touche aux données protégées, une API pour l'analyse complexe sur le reste : cette répartition donne plus de souveraineté réelle qu'un projet d'hébergement centralisé. Elle est aussi plus rapide à mettre en place.

Le modèle local sert de premier étage. Il classe, extrait, anonymise. Ce qu'il produit, un texte débarrassé de ses identifiants, ou une catégorie, peut ensuite partir vers un service externe si la tâche l'exige.

Cette architecture a une propriété appréciable : elle dégrade proprement. Si le service externe est indisponible, le premier étage continue de fonctionner et l'utilisateur garde une capacité réduite plutôt qu'aucune.

Elle suppose la même couche d'abstraction que le reste, ce qui permet de faire évoluer chaque étage indépendamment, le principe posé dans la couche qui rend le modèle remplaçable.

Un modèle sur le poste rend l'expérimentation possible sans autorisation préalable, ce qui accélère considérablement l'apprentissage collectif. C'est un effet secondaire important.

Dans une organisation contrainte, essayer quelque chose demande en général une validation : quelles données, quel service, quel contrat. Cette friction, légitime, empêche l'exploration.

Un modèle local supprime la friction pour toute une classe d'essais. Un collaborateur peut tester une idée sur ses propres documents sans engager quoi que ce soit, et c'est ainsi que les meilleurs cas d'usage émergent.

Cela suppose une règle claire sur ce qui reste local et ce qui ne l'est pas, et un minimum de littératie pour que chacun sache faire la différence, le sujet de former à tenir un système, pas à utiliser un outil.