Les LLM locaux évoluent plus vite qu'on ne le pense

Cela ne signifie pas que le cloud va disparaître, ni que tous les problèmes sont résolus. Mais l'idée que les modèles locaux ne sont encore que des jouets avec des limites évidentes n'est plus vraie. Ils ont encore des limites pour certains travaux agentiques et l'utilisation d'outils complexes. Mais pour l'extraction, la classification, la synthèse, la traduction, l'enrichissement et une part croissante du travail quotidien sur les données, ils sont assez performants pour changer la manière dont certains de nos systèmes sont conçus. Et cela pourrait déjà être plus impactant qu'on ne le pense.

Un nouveau vecteur d'opportunité

Pour une CDP, un CRM ou toute stack d'intelligence client, les modèles locaux offrent une nouvelle approche. Vous pouvez exécuter des inférences utiles directement près des données, sans tout envoyer en amont, sans transformer chaque demande en appel d'API, et sans faire du cloud une dépendance par défaut pour chaque fonctionnalité LLM. Ce que cela signifie concrètement:

Moins de données quittent le périmètre
Moins d'exposition
Moins de risques de data privacy
Moins de dépendances tierces intégrées dans l'architecture dès le départ

De l'ingénierie de caractéristiques à l'ingénierie de contexte

Beaucoup de l'intelligence client est construite une sortie à la fois. Un modèle pour le turnover, un autre pour le temps avant achat, un autre pour la segmentation, etc. Chaque score a sa propre logique, ses propres pipelines, sa propre gouvernance, son propre fardeau de maintenance. Cela fonctionne, mais cela fragmente les systèmes et en complexifie la gestion. Je ne pense pas que ce modèle durera éternellement. La fragmentation vient du concept lui-même. Chaque cas d'usage a besoin de ses propres données, donc chacun avec ses propres flux. À mesure que les modèles s'améliorent, la solution n'est plus de construire un modèle étroit pour chaque attribut, mais de reconnaître qu'une couche entière de données, notes CRM, transcriptions de support client, avis produits, conversations de vente, signaux mixtes, peut maintenant être enrichie, structurée et rendue opérationnelle d'une manière qui n'était pas réalisable ou économiquement viable auparavant.

Le feature engineering part de ce qu'on peut extraire proprement.
Le context engineering part de toutes les données déjà là.

L'ingénierie de caractéristiques part de ce qu'on peut extraire et calculer proprement. L'ingénierie de contexte part de toutes les données déjà là, y compris les parties désordonnées, et les transforme en entrée utilisable au moment où elles sont nécessaires. Prenons le churn comme exemple. Les deux approches partent du même problème, mais pas du même point de départ.

Feature Engineering• Variables explicatives: fréquence d'achat, delta RFM, historique de retours• Modèle entraîné sur ces variables, score publié• Une question = un modèle = un pipeline dédié• La question suivante réclame un nouveau projet

Context Engineering• Corpus existant: notes CRM, transcriptions support, tickets SAV• Modèle local interrogé à la demande sur ce corpus• "Ce client montre-t-il des signaux de rupture ?"• La question suivante utilise la même infrastructure

Ce n'est pas la fin de la modélisation structurée. Les scores explicites restent la bonne réponse pour certains cas d'usage, ils sont plus faciles à auditer, à gouverner, à évaluer et à industrialiser. Mais, dans un monde où une intelligence artificielle est abondante et bon marché, ils ne sont plus la seule option. Un nouveau modèle va émerger, où la connaissance est produite à partir d'un contexte à l'exécution au lieu d'être pré-intégrée dans un catalogue à sortie fixe. En pratique, cela rend les données précédemment inutilisables opérationnelles. Ces données existent dans presque tous les CRM et CDP, et elles ne sont connectées à rien d'opérationnel. Elles cessent d'être un poids mort et deviennent une entrée d'enrichissement directement exploitable.

Notes CRMCommentaires libres de conseillers commerciaux et d'avant-vente

TranscriptionsAppels et échanges de service client enregistrés

Résumés de rendez-vousComptes-rendus de visites en magasin ou en clientèle

Tickets SAVHistorique d'incidents, relances et résolutions

Avis produitsRetours clients structurés ou en texte libre

Emails entrantsDemandes, réclamations et échanges non structurés

Pour moi, cela est beaucoup plus proche de la promesse initiale de l'IA que les dernières années où tout le monde a créé des usines à scores. Le futur n'est pas de construire des automatisations autour de tâches étroites, mais des systèmes capables de répondre à de nouvelles questions sans avoir besoin d'un nouveau modèle, d'un nouvel ensemble de caractéristiques et de nouveaux flux chaque fois que quelqu'un demande quelque chose de légèrement différent.

Pourquoi cela devient "pratique" maintenant

Ce qui rend cela possible aujourd'hui, c'est que vous pouvez déjà exécuter des modèles réellement capables sur votre propre infrastructure, selon vos propres termes, sans que les données sensibles ne quittent le périmètre. Cet élan vient des publications récentes de modèles aux poids ouverts, en particulier provenant des laboratoires chinois. La famille Qwen3.5 d'Alibaba comprend désormais des modèles plus petits et plus denses ainsi que des variantes Mixture-of-Experts plus efficaces comme Qwen3.5-35B-A3B, qui n'active que 3 milliards de paramètres sur 35 milliards par token. DeepSeek-V3 est allé encore plus loin: 671B au total, 37B activés. Ce ratio entre capacité et coût d'inférence est là où l'utilisation locale devient pratique sur du matériel réel. Les outils aussi suivent le rythme. llama.cpp supporte la quantification à faible bit, plusieurs backends et l'inférence hybride CPU+GPU. Les gens exécutent des modèles utiles localement sur des machines limitées en échangeant précision, mémoire et latence de manière pragmatique. Nous n'avons plus besoin de matériel de datacenter. Et puis il y a la couche opérationnelle. Des outils comme llama-swap se placent devant les serveurs d'inférence locaux, changent de modèles à la demande, exposent des endpoints compatibles avec OpenAI et déchargent les modèles automatiquement après un TTL. L'écosystème évolue au-delà de la phase "choisissez un modèle et gardez-le". Nous pouvons tester, comparer et échanger des modèles à la volée. Ce qui rend tout cela intéressant, c'est que ces pièces peuvent maintenant fonctionner en même temps:

Architectures Open MoE
Inférence quantifiée
Chargement hybride CPU+GPU
Service de modèles interchangeables à chaud
Modèles spécialisés pour des tâches spécifiques

La pile est encore brute par endroits, mais elle existe, elle fonctionne et elle s'améliore rapidement. Les options compatibles avec une exécution locale et compliante ne sont plus les options faibles. L'inférence locale devient une solution pratique. Bien que je vous l'accorde, l'architecture décrite ici reste simpliste.

Ce qui change pour l'intelligence client

Une fois que les modèles sont suffisamment bons, le goulot d'étranglement se déplace. Actuellement, la contrainte est souvent la mémoire RAM, c'est l'écart entre "ça marche" et "ça marche vraiment bien". Mais c'est un problème d'ingénierie avec une trajectoire connue. Le changement plus significatif est dans ce que devient le profil client maintenant que des modèles bon marché peuvent traiter, enrichir et raisonner sur les données brutes qui y sont liées. Il cesse d'être simplement un endroit pour y stocker des attributs. Il devient une couche de contexte interrogeable et enrichissable dynamiquement, pour répondre à de nombreuses questions en même temps. Un exemple concret: un responsable CRM veut comprendre pourquoi un segment premium montre des signes d'érosion.

Approche scoring1. Identifier les variables pertinentes du segment2. Construire ou adapter un pipeline dédié3. Attendre l'exécution, valider les résultats4. Résultat partiel, une seule question traitée

Couche de contexte1. Requête sur l'historique de contact du segment2. Notes libres et tickets inclus automatiquement3. Réponse structurée en quelques minutes4. La question suivante utilise la même infrastructure

Les modèles explicites de scoring ne disparaissent pas. Ils deviennent une couche d'intelligence à l'intérieur du système, pas le système entier.

Quelle est la prochaine étape ?

La vraie question n'est plus de savoir si les modèles LLM sont suffisamment bons aujourd'hui. Ils le sont. La question est de savoir si les équipes Data CDP et CRM sont prêtes à cesser de traiter chaque nouvelle question comme une raison de construire une autre pipeline entière. Parce que les stacks LLM actuelles permettent désormais une approche différente: moins centrée sur des sorties fixes, plus sur un contexte réutilisable et un raisonnement à l'exécution. Il ne s'agit pas de remplacer le CRM ou les CDP. Il s'agit de les faire évoluer. Les équipes qui comprendront cela en premier ne se contenteront pas d'aller plus vite. Elles répondront à des questions que leurs concurrents sont encore en train de commencer à définir comme de futurs projets. Si cela résonne avec ce que vous construisez, je serais ravi d'en discuter avec vous. Vous pouvez me joindre à octave@olivetti.ai.

Du Feature Engineering au Context Engineering