Blog¶

Comment évaluer un finetuning avant la mise en prod ?

Comment évaluer un finetuning avant la mise en prod ?

Évaluer un finetuning avant la prod revient à répondre à trois questions, pas une seule : est-ce que le modèle progresse vraiment sur la tâche visée, est-ce qu'il régresse ailleurs, et est-ce que l'écart mesuré est réel ou du bruit. Un finetuning qui gagne des points sur son propre jeu de test mais en perd sur des capacités qu'il maîtrisait déjà n'est pas un progrès. C'est un déplacement du problème, souvent invisible tant qu'on ne va pas le chercher.

Ce triptyque, tâche cible, canary set contre l'oubli catastrophique, holdout scellé, c'est ce qui sépare un finetuning qu'on peut shipper d'un finetuning qui a l'air bon dans le playground et qui déçoit en production.

Classifier du texte avec BERT, un SLM ou une API LLM ?

BERT, SLM ou API LLM pour classifier du texte ?

Pour classifier du texte en 2026, trois familles de solutions coexistent. Il y a l'encodeur finetuné (BERT, RoBERTa, DeBERTa, CamemBERT), le SLM génératif en few-shot (Qwen, Llama, Phi) et l'API LLM en zero-shot (GPT, Claude). Sur une tâche cadrée avec des données annotées, l'encodeur finetuné est en général le plus précis et le moins cher à l'inférence. Sans données ni taxonomie stable, le LLM ou le SLM génératif prennent le relais.

Le réflexe du moment est de tout envoyer à une API LLM. C'est souvent le choix le plus cher et le moins précis sur une tâche de classification bien cadrée, et je le vois régulièrement en mission.

Classification d'intentions par LLM et gestion de l'incertitude

Classifier des intentions avec un LLM, la baseline avant tout

Classifier des messages en intentions avec un LLM commence par une baseline, pas par un finetuning. Un petit modèle open source (SLM) de moins de 500 millions de paramètres, un prompt strict avec quelques exemples et une sortie structurée donnent souvent une première mesure exploitable. Le vrai piège n'est pas de forcer un JSON valide en sortie, c'est de savoir quand ne pas lui faire confiance.

J'ai eu ce projet récemment, ranger des messages utilisateur dans huit classes d'intention, avec un modèle assez petit pour tourner en production sans exploser la latence ni la facture. Le réflexe du prompt strict et de la sortie structurée a bien fonctionné dès le départ. Ce qui m'a pris plus de temps, c'est de comprendre pourquoi certaines prédictions confiantes en apparence ne l'étaient pas du tout.

Générer des données synthétiques pour entraîner un LLM

Générer des données synthétiques pour entraîner un modèle, pourquoi et comment ?

Générer des données synthétiques sert à combler un manque, un jeu de données réel trop petit, trop sensible, ou trop coûteux à annoter. Ce n'est pas une astuce pour aller plus vite, c'est une réponse à un manque mesuré. La règle ne change jamais. On ancre la génération sur du réel, on vérifie ce qu'on produit, et on ne touche jamais au jeu de test.

Comment entraîner un SLM (Small Language Model) ?

Comment entraîner un SLM, et faut-il vraiment le faire ?

Entraîner un SLM peut vouloir dire plusieurs choses très différentes : finetuner un petit modèle existant sur vos données, en distiller un à partir d'un gros, ou en entraîner un depuis zéro. Pour 95 % des entreprises, la bonne réponse est le fine-tuning, et seulement après avoir vérifié qu'un modèle existant ne suffisait pas déjà.

C'est le premier réflexe à avoir, et il fait gagner beaucoup de temps et d'argent. Avant de lancer le moindre entraînement, testez ce qu'un bon petit modèle open source donne déjà avec du prompt engineering, quelques exemples et une sortie structurée. Mesurez. On ne s'autorise à entraîner que si la mesure montre que ça ne suffit pas.

IA locale : faire tourner un SLM en local (on-premise)

IA locale : pourquoi et comment faire tourner un SLM chez soi

Faire tourner un SLM en local, c'est exécuter un modèle de langage sur votre propre machine ou votre propre serveur, sans passer par une API externe. C'est devenu réaliste parce que les petits modèles sont assez bons et assez légers pour ça, et c'est souvent le bon choix pour trois raisons : la confidentialité, le coût, et la latence.

Concrètement, vos données ne quittent jamais votre infrastructure, vous ne payez plus au token, et le modèle répond vite, même hors ligne. Pour une entreprise qui manipule des données sensibles ou qui traite du volume, ces trois arguments pèsent lourd.

SLM vs LLM : quand choisir un petit modèle ?

SLM vs LLM : quand choisir un petit modèle ?

Le choix entre un SLM et un LLM se résume à une question : votre tâche est-elle précise et répétitive, ou large et imprévisible ? Sur une tâche cadrée comme classer, extraire ou router, un petit modèle (SLM) spécialisé suffit souvent, coûte de 15 à 50 fois moins cher et répond plus vite. Sur du raisonnement ouvert, de la culture générale ou des tâches très variées, un gros modèle (LLM) reste devant.

Et en production, la vraie réponse est souvent : les deux. Le petit modèle absorbe le volume, le gros intervient sur les cas difficiles.

C'est tout le sujet de cet article. Plutôt que de répéter ce qu'est un petit modèle, sujet que je traite dans mon article sur ce qu'est un SLM et pourquoi en 2026, je vais ici poser une grille de décision chiffrée pour trancher entre les deux sur un projet réel.

SLM : c'est quoi un Small Language Model et pourquoi en 2026

SLM : pourquoi faire petit quand on peut faire gros ?

Un SLM (Small Language Model, ou petit modèle de langage) est un modèle de langage de petite taille, en général sous les 10 milliards de paramètres, capable de tourner sur une machine modeste tout en restant bon sur des tâches précises. C'est exactement la même technologie qu'un LLM comme ChatGPT, en beaucoup plus petit, plus rapide et moins cher.

On en parle beaucoup moins que du RAG ou des agents IA. Pourtant, sur un projet en production, le choix de la taille du modèle est l'une des décisions les plus concrètes qu'on ait à prendre, et elle se résume souvent à trois mots : coût, latence, confidentialité.

Parce qu'en production, la vraie question n'est pas "quel est le modèle le plus impressionnant". C'est "quel est le plus petit modèle qui fait le travail correctement". Un SLM, c'est exactement cette question posée à voix haute.

AI Engineer : le nouveau rôle du data scientist en IA générative

AI Engineer : qui c'est, et pourquoi le terme existe

Un AI engineer, c'est celui qui intègre des modèles d'IA générative en production sans les entraîner lui-même. Il part de modèles existants, des LLM accessibles par API ou en open source, et son travail consiste à les transformer en quelque chose d'utile et de fiable : un RAG, un agent, une chaîne de traitement qui tient en production. C'est un rôle qui n'existait pas vraiment il y a trois ans.

Je suis Anas Rabhi, data scientist freelance, et c'est de plus en plus comme ça que je décris ce que je fais. C'est surtout une nouvelle appellation. En data science, le rôle a toujours bougé selon les capacités de chacun et selon ce dont l'entreprise avait besoin : la même personne a pu être appelée data scientist, ingénieur IA, machine learning engineer, parfois les trois. « AI engineer » est la dernière de ces étiquettes, celle qui colle au travail qu'on fait depuis l'arrivée de l'IA générative. Cet article explique ce qu'elle recouvre, pourquoi elle est apparue, et en quoi elle diffère du data scientist et du ML engineer.

Réussir un projet IA : ce qui se joue avant le code

Réussir un projet IA se décide avant la première ligne de code

Ce qui fait qu'un projet IA fonctionne se décide bien avant de toucher au moindre bout de code. Pas dans le choix du modèle, pas dans le framework, pas dans le pipeline. Dans le cadrage : la problématique métier, l'objectif et sa mesure, la donnée réelle, la question de savoir si l'IA est même nécessaire, et l'utilisateur qui devra s'en servir.

Avec le temps, j'ai fini par passer le plus clair de mon énergie sur ce qui vient avant l'IA. Pas sur l'IA elle-même. C'est contre-intuitif quand on est ingénieur, mais c'est là que se joue la différence entre un projet qui tient et un projet qui finit dans un tiroir.