Du feature engineering au context engineering

Pendant des années, l’intelligence client a progressé une sortie à la fois. Un score de churn, un délai avant achat, une segmentation, puis un nouveau pipeline dès qu’une nouvelle question apparaissait.

Cette architecture a une qualité : chaque résultat peut être défini, évalué et industrialisé. Elle a aussi un coût. Les modèles, les variables et les flux s’accumulent jusqu’à former un catalogue de réponses décidées à l’avance.

Les LLM locaux ouvrent une autre voie. Ils permettent d’exploiter les notes CRM, les tickets SAV, les transcriptions et les avis produits près des données, sans transformer chaque question en projet de scoring.

Le changement important n’est pas la disparition du feature engineering. C’est l’arrivée d’une couche de contexte réutilisable à côté des modèles structurés.

#Une question, un modèle, un pipeline

Le feature engineering transforme des données stables en variables utilisables par un modèle. Pour estimer le risque de churn, on peut calculer la fréquence d’achat, l’évolution du panier, les retours ou le temps écoulé depuis le dernier contact.

Cette méthode reste solide lorsque la question est stable et répétée. Le score peut être suivi dans le temps, comparé à une réalité observée et intégré dans une campagne avec des règles claires.

La limite apparaît quand les questions changent plus vite que les pipelines. Pourquoi ce segment premium s’érode-t-il ? Quels irritants reviennent dans les échanges récents ? Quels signaux faibles n’entrent dans aucune colonne du profil client ?

Les deux approches ne produisent pas le même objet. L’une fournit un signal stable pour une décision répétée. L’autre aide à explorer une situation dont les causes sont dispersées dans plusieurs sources.

#Les parties désordonnées deviennent utiles

Une grande partie de la connaissance client existe déjà sous une forme difficile à exploiter. Elle se trouve dans les commentaires libres, les conversations ou les comptes-rendus que les pipelines traditionnels laissent souvent de côté.

Le context engineering ne consiste pas à verser toutes ces données dans un prompt. Il faut sélectionner les sources utiles, appliquer les droits d’accès, conserver la provenance et demander une sortie exploitable. Le contexte doit être construit avec autant de soin qu’un pipeline.

C’est à cette condition que les parties désordonnées deviennent opérationnelles. Elles cessent d’être un poids mort dans le CRM et apportent des éléments que les attributs structurés ne capturent pas seuls.

#Pourquoi l’inférence locale change la frontière

Cette approche devient plus crédible parce que des modèles capables peuvent maintenant fonctionner sur une infrastructure maîtrisée. L’inférence locale réduit les transferts de données et la dépendance à une API tierce. Elle ne rend pas automatiquement le système conforme ou sécurisé.

Le modèle Qwen3.5-35B-A3B compte 35 milliards de paramètres au total, mais en active 3 milliards par token. Cette architecture MoE réduit le calcul effectué à chaque étape. Elle ne supprime pas la mémoire nécessaire pour stocker les poids du modèle, même si la quantification permet de la réduire fortement.

DeepSeek-V3 pousse le principe beaucoup plus loin avec 671 milliards de paramètres au total et 37 milliards activés par token. C’est un signal important sur l’évolution des architectures, pas la preuve qu’un modèle de cette taille devient soudain adapté à une machine ordinaire.

La couche logicielle progresse en parallèle. llama.cpp prend en charge la quantification à faible précision, plusieurs backends matériels et l’inférence hybride CPU+GPU. llama-swap ajoute le changement de modèle à la demande, des endpoints compatibles OpenAI et le déchargement automatique après un TTL.

Ces outils ne suppriment pas les compromis entre qualité, mémoire et latence. Ils permettent de les piloter sur une infrastructure plus simple, avec plusieurs modèles spécialisés derrière une interface commune.

#Le profil client devient une couche de contexte

Le profil client ne se limite alors plus à une collection d’attributs calculés à l’avance. Il peut donner accès, sous contrôle, aux éléments utiles pour répondre à une question nouvelle.

Prenons un responsable CRM qui cherche à comprendre l’érosion d’un segment premium :

1. Le segment et les droits d’accès définissent le périmètre.
2. Le système récupère les notes, tickets et transcriptions autorisés.
3. Le modèle extrait les signaux récurrents et renvoie une réponse structurée avec ses sources.
4. Le responsable valide l’analyse avant toute décision ou activation.

La question suivante peut utiliser la même infrastructure avec un autre contexte. Cela ne garantit pas une bonne réponse. Cela évite de reconstruire toute la chaîne avant même de pouvoir explorer le problème.

Les modèles explicites ne disparaissent pas. Ils deviennent une couche d’intelligence dans le système, pas le système entier.

#Choisir le bon mode de production

Un score structuré reste préférable pour une décision fréquente, mesurable et fortement automatisée. Une couche de contexte devient intéressante pour une question exploratoire, des sources narratives ou un besoin qui évolue rapidement.

Le choix n’oppose donc pas l’ancien et le nouveau. Il porte sur la nature de la décision, le niveau d’audit attendu et le coût d’une erreur. Dans les deux cas, il faut des données autorisées, des critères d’évaluation et un responsable clairement identifié.

Le vrai déplacement est là : l’intelligence client n’est plus limitée aux attributs décidés lors de la conception du pipeline. Elle peut aussi mobiliser un contexte gouverné pour répondre à des questions qui n’existaient pas encore.

Les modèles locaux rendent cette évolution possible sans la rendre simple. C’est précisément pour cela que le produit, l’architecture et la gouvernance doivent avancer ensemble.

Si cette évolution rejoint les questions que vous vous posez sur votre CRM ou votre CDP, vous pouvez me joindre à octave@olivetti.ai.