Vu de l’extérieur, un grand modèle de langage paraît presque magique. Son mécanisme de base est pourtant beaucoup plus simple : il estime, encore et encore, quel token devrait venir ensuite. Ce qui est remarquable, c’est tout ce qui émerge lorsque ce moteur de prédiction a absorbé suffisamment d’exemples de langage, de code, de raisonnement et de résolution de problèmes.

Tout commence par les tokens

Le modèle ne lit pas une phrase comme nous lisons des mots. Il la découpe en tokens : parfois un mot entier, parfois une partie de mot, un signe de ponctuation ou un fragment de code. En anglais, un token représente grossièrement trois quarts de mot ; en français et dans les contenus techniques, le ratio varie. C’est pourquoi un document de 10 000 mots ne correspond pas à 10 000 tokens facturés.

À l’inférence, le modèle regarde les tokens déjà présents, calcule une distribution de probabilité pour le suivant, en choisit un, l’ajoute à la séquence, puis recommence. Cette boucle très simple explique pourquoi le texte apparaît progressivement à l’écran.

Le rôle de l’attention

Ce qui rend cette prédiction réellement utile est le mécanisme d’attention. Imaginez une table de réunion couverte de notes. Avant de produire le prochain mot, le modèle attribue davantage de poids aux éléments qui semblent pertinents pour la suite. Un « il » peut renvoyer vers le nom d’un équipement cité trois paragraphes plus tôt ; un calcul peut concentrer l’attention sur les chiffres et les opérateurs proches ; une question contractuelle sur la clause qui définit précisément un terme.

C’est le cœur de l’architecture Transformer. L’attention n’offre ni mémoire infinie ni garantie que le bon passage dominera. Elle permet simplement au modèle de pondérer les relations entre les éléments qui sont actuellement dans son champ de vision.

La connaissance n’est pas stockée comme dans une base de données

Un modèle entraîné contient des milliards, parfois des centaines de milliards, de paramètres appris. Ces paramètres capturent des régularités statistiques issues des données d’entraînement. Ils ne sont pas des lignes de table que le modèle peut interroger. Il peut restituer un fait parce que le motif est fortement inscrit dans ses poids, mais il ne peut pas ouvrir un enregistrement interne et montrer « voici l’endroit où ce fait est stocké ».

Cette différence explique l’hallucination, ou plus précisément la confabulation. Le même mécanisme produit une réponse exacte et une réponse fausse mais plausible. La fluidité n’est donc jamais une preuve de vérité. Un modèle peut formuler une erreur avec une assurance parfaite.

Les informations récentes sont également externes. L’entraînement et le post-entraînement s’arrêtent à des périodes déterminées. Si un assistant vous parle d’un événement arrivé hier, le produit qui l’entoure a généralement récupéré des informations fraîches grâce à une recherche web, une base, une API ou un autre outil, puis les a placées dans le contexte. Le modèle n’a pas « appris » l’actualité pendant la nuit.

La fenêtre de contexte : le bureau de travail du modèle

La fenêtre de contexte contient tout ce que le modèle peut utiliser pour l’inférence en cours : votre consigne, l’historique utile, des extraits retrouvés, la description des outils, des fichiers, des enregistrements structurés et, dans un système multimodal, des représentations d’images, d’audio ou de vidéo. Sa taille se mesure en tokens.

L’image juste est celle d’un bureau, pas d’une armoire d’archives. Ce qui est posé sur le bureau peut influencer la réponse. Ce qui reste ailleurs est invisible jusqu’à ce que l’application aille le chercher. En 2026, certains modèles annoncent des fenêtres de plusieurs centaines de milliers à environ deux millions de tokens. Une capacité maximale ne signifie pourtant pas qu’il faut la remplir.

Un contexte très long entraîne trois coûts à la fois : davantage de tokens en entrée, plus de latence et davantage de concurrence entre informations utiles et bruit. Les travaux sur le long contexte montrent régulièrement des variantes de ce phénomène, parfois décrit comme context rot ou effet « lost in the middle ». Un grand bureau est pratique. Le recouvrir de tous les dossiers de l’entreprise ne l’est pas.

La mémoire est une fonction du système

Le modèle raisonne uniquement sur ce que l’inférence courante lui présente. Une application peut reconstruire elle-même cet état, ou un fournisseur peut conserver l’historique côté serveur et le réinjecter. Dans les deux cas, la mémoire durable vient d’un stockage, d’une politique et d’un mécanisme de récupération autour du modèle. Ce n’est pas un souvenir personnel caché dans ses poids.

Comment un modèle de base devient un assistant

Quand on parle « du modèle », on regroupe en réalité plusieurs étapes. Les distinguer permet de comprendre la différence entre pré-entraînement, post-entraînement, fine-tuning et ingénierie du système.

• Pré-entraînement. Le modèle apprend les régularités générales du langage et du monde sur de très grands volumes de données en prédisant des tokens manquants ou suivants. Cela crée une capacité générale, pas forcément un bon assistant.
• Instruction et post-entraînement. On lui montre des exemples de questions, réponses, appels d’outils et comportements souhaités afin qu’il suive une tâche plutôt que de simplement continuer du texte.
• Entraînement par préférence ou renforcement. Des retours humains ou générés par d’autres modèles rendent certains comportements plus probables et d’autres moins probables. Les laboratoires emploient des variantes différentes.
• Spécialisation. Fine-tuning, adapters, distillation ou post-entraînement métier peuvent modifier durablement le comportement pour un usage précis.
• Inférence. C’est l’étape que vous payez à chaque exécution. Prompts, RAG, outils et boucles agentiques se produisent ici, autour d’un modèle déjà entraîné.

Cette distinction donne une règle utile pour la suite : utilisez le prompt pour dire quoi faire maintenant, le retrieval pour apporter des faits qui changent, des outils pour agir sur des systèmes et le fine-tuning lorsque vous voulez modifier un comportement de manière stable à travers de nombreux exemples. Le fine-tuning remplace rarement une base de connaissances.

Les modèles de raisonnement et le « thinking »

Les modèles dits de raisonnement consacrent davantage de calcul à des étapes intermédiaires avant de produire leur réponse finale. Selon le fournisseur, on parle de reasoning, thinking, deliberation ou budget de raisonnement. Mécaniquement, cela reste de l’inférence, mais cette dépense supplémentaire peut améliorer nettement les mathématiques, la planification, le code ou les problèmes à plusieurs étapes.

Le compromis est réel : plus de raisonnement signifie souvent plus de tokens ou de calcul, plus de latence et plus de coût. Ce n’est pas un interrupteur universel de qualité. Sur l’extraction, la synthèse fidèle, le routage ou des réponses très encadrées par des sources, davantage de raisonnement peut n’apporter presque rien et parfois pousser le modèle à inférer au-delà de ce qui est fourni. Il faut tester le niveau de raisonnement sur la tâche, pas supposer que « plus » est toujours « mieux ».

Température, top-p et top-k

Une fois la distribution de probabilité calculée, il reste à choisir le prochain token. Les paramètres d’échantillonnage modifient cette sélection. Ils influencent surtout la variabilité de la réponse, pas sa vérité.

La température rend la distribution plus ou moins plate. À faible température, le modèle privilégie fortement les tokens les plus probables ; en l’augmentant, on donne davantage de chances à des options moins probables. Cela peut produire plus de variété, mais aussi plus d’instabilité.

Top-p, ou échantillonnage nucleus, ne garde que le plus petit ensemble de tokens dont la probabilité cumulée dépasse un seuil donné. Top-k conserve simplement les k candidats les plus probables. En pratique, évitez de modifier plusieurs paramètres à la fois sans protocole d’évaluation : leurs effets se combinent.

Cette section peut faire économiser plus d’argent que beaucoup d’optimisations de modèles. Une part importante des « projets IA » industriels ne sont pas des problèmes de langage. Y appliquer un LLM produit souvent une version coûteuse et moins fiable d’une technique plus simple.

IA ne veut pas dire LLM

Le machine learning est présent dans l’industrie depuis des décennies : contrôle statistique, vision, prévision, maintenance conditionnelle, optimisation. Depuis 2023, une branche particulière est devenue conversationnelle et a absorbé presque tout le vocabulaire. Dans de nombreux comités de direction, « IA » est devenu synonyme de « chatbot ».

La conséquence est prévisible : on décrit un problème, l’équipe pense immédiatement LLM, puis le pilote déçoit six mois plus tard. Pas forcément parce que le modèle était mauvais, mais parce que le signal utile n’était jamais dans le langage.

La première question à poser

Où se trouve principalement le signal : dans des mots et des documents, ou dans des chiffres, des séries temporelles, des capteurs et des pixels ?

Les modèles de langage excellent à lire, synthétiser, classer du texte, rédiger, extraire des informations de documents et dialoguer. Ils sont beaucoup moins adaptés à l’extrapolation numérique fiable, aux intervalles de confiance, à l’optimisation sous contraintes ou à la détection déterministe à très faible latence. C’est précisément là que les méthodes classiques sont fortes.

Le plus intéressant est souvent hybride

Dans beaucoup de systèmes industriels, le meilleur dessin est : la méthode spécialisée calcule ou détecte ; le modèle de langage explique, recherche et déclenche le workflow.

Un modèle de prévision produit la demande et son intervalle ; un LLM explique les facteurs principaux à un responsable de production. Un détecteur d’anomalie identifie un roulement suspect ; un LLM retrouve l’historique de maintenance et prépare l’ordre de travail. Un modèle de vision localise le défaut ; un LLM rédige la non-conformité et rapproche les cas antérieurs.

Les petits modèles spécialisés ont encore beaucoup de valeur

Un modèle de gradient boosting entraîné sur vos historiques peut tenir sur un ordinateur portable, coûter pratiquement zéro par prédiction, être reproductible et fournir une importance des variables. Sur un problème tabulaire étroit, il peut largement battre un modèle généraliste. Ce n’est pas spectaculaire en démonstration, mais c’est souvent la solution d’ingénierie correcte.

Prompt engineering, context engineering, harness engineering, orchestration agentique : ces disciplines ne s’opposent pas. Elles correspondent à des couches différentes autour du même moteur. Pour Ascentis, les regrouper en quatre niveaux donne une carte beaucoup plus utile que la succession de nouveaux termes.

1. Le prompt décrit la tâche, les contraintes, le rôle, le format et éventuellement des exemples.

2. Le contexte contient les informations disponibles pour cette exécution : historique, documents retrouvés, enregistrements, mémoire, exemples et description des outils.

3. La couche d’exécution, ou harness encadre ce que le modèle peut réellement toucher : outils, API, sandbox, permissions, secrets, contrôles de schéma, limites, journalisation.

4. La boucle définit ce qui se passe après une première action : vérifier, recommencer, changer de stratégie, escalader, demander une validation ou s’arrêter.

Le prompt n’est plus le principal goulot d’étranglement des systèmes modernes, mais c’est toujours l’interface la plus directe avec le modèle. Quelques habitudes simples changent davantage la qualité qu’une collection de « formules magiques ».

Donnez le contexte qu’exigerait un nouveau collègue

« Rédige un mail de relance » est incomplet pour un humain comme pour un modèle. Quel client ? Quelle relation ? Qu’a-t-on déjà convenu ? Quel résultat voulez-vous ? Quel ton ? Si vous laissez ces éléments vides, le modèle doit soit les inventer, soit produire une réponse générique.

Décrivez la sortie attendue, pas seulement la tâche

Précisez longueur, structure, niveau de détail, audience, ton et contraintes. « Trois points, moins de quinze mots chacun, décision en premier » produit un objet directement exploitable. « Résume ce texte » laisse au modèle le soin de deviner ce qui vous sera utile.

Montrez quelques bons exemples

Deux ou trois couples entrée → sortie représentatifs sont souvent plus efficaces qu’une page d’explications. C’est le few-shot prompting. Choisissez des cas canoniques plutôt qu’une collection d’exceptions : le modèle doit comprendre le motif principal.

Un registre de contraintes, repris dans chaque prompt

Sur une mission d’entrée de marché de huit semaines, tout le pipeline de recherche partait d’un fichier de contraintes numéroté — seize règles plus un registre NDA — placé en tête de chacun des quarante-deux prompts, plutôt que reformulé de mémoire. Quatre-vingt-dix conversations plus tard, les contraintes n’avaient pas dérivé, parce qu’elles n’existaient qu’à un seul endroit.

Séparez clairement les instructions des contenus

Quand vous fournissez un document, marquez où commencent et finissent la consigne, la source et les données à analyser. Titres Markdown, balises XML légères ou blocs distincts réduisent l’ambiguïté et préparent aussi le terrain à la sécurité contre la prompt injection.

À quoi ressemble une abstention réussie en production

Sur un système de veille hebdomadaire, chaque signal est relu dans le marché où il s’est produit. Quand le système ne parvient pas à replacer un signal dans son contexte local, l’échec prévu est de le restituer sans relecture — jamais d’en inventer une plausible. Sur deux cents signaux et cinq territoires à la recette, aucune étape n’a dégradé vers une interprétation fabriquée.

Dites-lui ce qu’il doit faire quand l’information manque

« Si le document ne donne pas cette valeur, écris “non indiqué”. Ne l’infère pas. » C’est l’un des contrôles les moins chers en IA appliquée. Si vous demandez uniquement une sortie complète, le modèle est incité à la rendre complète, même lorsque la source ne l’est pas.

Traitez les hypothèses comme des hypothèses

Étiquetez ce que vous savez, ce que vous supposez et ce qui reste à vérifier. Par exemple : « Nous pensons que ce concurrent utilise un éclairage halogène ; source : conversation non vérifiée sur un salon. Vérifie et qualifie le niveau de preuve. » Sans cette séparation, une supposition peut devenir silencieusement une prémisse du raisonnement.

Utilisez la conversation pour corriger précisément

Un bon prompt n’a pas besoin d’être parfait au premier essai. « Le fond est bon mais la recommandation est trop enfouie ; mets la décision et l’échéance au début » est souvent plus efficace que de reconstruire une consigne de cinquante lignes. La conversation fait partie de l’interface.

Prompt, retrieval, outils ou fine-tuning ?

Ce choix devient beaucoup plus simple lorsqu’on demande ce qui manque réellement au modèle.

• Une meilleure instruction pour cette tâche : prompt.
• Des informations privées, récentes ou changeantes : retrieval / RAG.
• La capacité de lire ou modifier un système : outil / API.
• Un comportement récurrent que vous voulez rendre plus stable sur des centaines d’exemples : fine-tuning.

Les combinaisons sont normales. Un agent support peut utiliser un prompt pour son rôle, un RAG pour la documentation, des outils pour le CRM et un modèle finement adapté pour un style ou un format particulier.

Le contexte est une ressource finie. Le but n’est pas d’en fournir le plus possible, mais de composer, à chaque étape, le paquet d’information le plus utile et le moins bruité.

Écrire

Sortez l’état durable de la fenêtre de contexte. Un résultat intermédiaire, une décision validée, un identifiant, un résumé de dossier ou l’étape atteinte dans un workflow doivent vivre dans une base, un fichier ou un store d’état. Le contexte peut alors être reconstruit proprement à la prochaine exécution.

Sélectionner

N’apportez que ce qui est utile à l’étape courante : passages retrouvés, enregistrements du bon client, outils réellement pertinents, historique nécessaire. La sélection se fait par retrieval, filtrage, routage et politiques d’accès.

Compresser

Un historique de trente pages peut parfois devenir un résumé de dix lignes plus les trois décisions encore ouvertes. Une réponse d’API de 200 champs peut être réduite à six valeurs utiles. La compression est un travail d’ingénierie, pas simplement « résumer plus court ».

Isoler

Lorsque plusieurs sous-tâches n’ont pas besoin du même contexte, séparez-les. Un worker chargé d’analyser un contrat n’a pas besoin de l’historique complet d’un autre agent qui planifie une intervention. Cette isolation réduit le bruit, le coût et parfois le risque de permission.

La sécurité fait partie du contexte

Un modèle ne devrait pas voir une information simplement parce qu’elle se trouve dans votre index. Les filtres de tenant, rôle, ACL et sensibilité doivent être appliqués avant que le contenu n’entre dans son champ de vision. Une permission « vérifiée après la génération » arrive trop tard.

Le RAG, pour retrieval-augmented generation, transforme une question de mémoire en examen à livre ouvert. Au lieu d’espérer que le modèle « connaisse » votre documentation, l’application retrouve les passages pertinents au moment de la question et les lui donne comme preuves.

Le pipeline de base

1. Ingestion. Lire les fichiers et conserver autant que possible leur structure : titres, pages, tableaux, métadonnées, permissions.
2. Découpage. Former des passages assez autonomes pour être retrouvés, sans casser le sens.
3. Indexation. Créer des représentations sémantiques et/ou lexicales, en conservant les métadonnées utiles.
4. Recherche. Transformer éventuellement la question, puis récupérer un ensemble suffisamment large de candidats.
5. Reranking. Reclasser les candidats avec un modèle qui lit la question et le passage ensemble.
6. Génération. Donner au LLM un petit jeu de preuves à fort signal, demander des citations ou identifiants de source et autoriser l’abstention.

Le découpage est un choix métier

Un chunk n’est pas juste « 500 tokens ». Pour une procédure, il peut être judicieux de garder une étape avec ses conditions. Pour un contrat, une clause entière avec son titre. Pour un manuel technique, un défaut avec ses causes et actions. Le meilleur découpage préserve l’unité de sens que les utilisateurs cherchent réellement.

Recherche hybride

Les embeddings sont forts sur le sens mais peuvent rater un SKU, un code erreur, une référence normative ou un nom exact. La recherche lexicale fait souvent l’inverse. Exécuter les deux puis fusionner les classements est donc un excellent point de départ pour des corpus techniques et métiers.

Reranking

Si le bon passage se trouve régulièrement dans les candidats mais trop bas dans la liste, un reranker est souvent une amélioration à très fort rendement. Il ne peut en revanche pas récupérer un document que le premier étage n’a jamais trouvé.

Les permissions et la suppression font partie du RAG

Un index de production doit respecter les droits du système source. Si une personne ne peut pas ouvrir un document dans SharePoint, l’assistant ne doit pas pouvoir en révéler le contenu simplement parce qu’un embedding existe. Conservez tenant, ACL, classification et identifiant source pendant l’ingestion et appliquez les filtres avant ou pendant la recherche.

La suppression doit elle aussi se propager. Effacer le PDF d’origine ne suffit pas si des copies subsistent dans du texte parsé, de l’OCR, des chunks, des vecteurs, un index lexical, un graphe ou un cache sémantique.

Une architecture robuste marque immédiatement la source comme supprimée, bloque sa récupération, déclenche une purge idempotente de toutes les représentations dérivées, réessaie jusqu’à réussite puis vérifie qu’aucun chemin actif ne peut encore la retourner. Cela exige un identifiant de lignée conservé sur chaque objet dérivé.

Pour les données personnelles soumises à un droit d’effacement valide, les obligations européennes et britanniques peuvent concerner les sauvegardes et copies dérivées. Lorsqu’un effacement immédiat dans une sauvegarde n’est pas techniquement possible, l’objectif est de mettre la donnée hors d’usage jusqu’à son expiration normale, tout en conservant une politique claire pour les journaux de sécurité ou preuves soumises à une obligation distincte de conservation.

Quand le RAG n’est pas le bon outil

• Tout tient proprement dans le contexte. Pour un petit corpus stable, un contexte direct peut être plus simple.
• La question est un calcul de base de données. « Chiffre d’affaires par région au T3 » relève de SQL ou d’une couche sémantique.
• La réponse dépend de relations explicites. Chaînes de propriété, dépendances ou sanctions peuvent exiger un graphe ou un modèle structuré.
• La source change en permanence. Si la fraîcheur seconde par seconde est essentielle, interrogez directement le système de référence.

Long contexte et retrieval sont complémentaires

Une grande fenêtre réduit certaines contraintes, mais ne supprime pas le besoin de choisir l’information. Envoyer un million de tokens à chaque question coûte plus cher, prend plus de temps et ajoute du bruit. Le long contexte permet d’apporter davantage de preuves lorsque c’est nécessaire ; il ne fait pas disparaître la pertinence comme problème d’ingénierie.

RAG agentique

Dans un RAG fixe, on cherche une fois puis on répond. Dans un RAG agentique, la recherche devient un outil : le modèle peut reformuler, chercher ailleurs, comparer plusieurs sources et décider qu’il lui manque encore quelque chose. C’est puissant pour des questions ouvertes ou multi-sources, mais cela ajoute coût, latence et modes de panne. Les requêtes simples devraient continuer à passer par un chemin court.

Évaluez la recherche avant la génération

Constituez un jeu de vraies questions et identifiez pour chacune les éléments qui devraient être retrouvés. Mesurez si le moteur les remonte. Si le passage nécessaire n’entre jamais dans le jeu de candidats, aucun prompt ne pourra le recréer. Cette séparation entre évaluation du retrieval et évaluation de la génération est l’une des disciplines les plus importantes d’un RAG en production.

Cherchez « types de RAG » et vous trouverez des listes de trois, neuf, douze ou davantage. Elles ne se contredisent pas forcément : elles comptent simplement des choses à des niveaux différents. La littérature parle de grandes familles ; les équipes produit ont besoin de motifs d’architecture qu’elles peuvent choisir face à un échec concret.

Trois grands niveaux de vocabulaire

Une taxonomie académique largement reprise distingue Naive RAG, Advanced RAG et Modular RAG. C’est une bonne manière de raconter l’évolution du domaine, pas une norme officielle. Ici, nous utilisons un niveau plus opérationnel : neuf motifs pratiques qui permettent de relier un problème observable à une réponse d’architecture.

Ce que l’entreprise veut généralement obtenir

Derrière les acronymes, beaucoup de projets poursuivent la même promesse : une interface conversationnelle capable de répondre à partir des informations de l’organisation et de montrer d’où vient la réponse. Les raffinements existent parce qu’il est beaucoup plus difficile de tenir cette promesse de manière fiable que de réussir une démonstration.

1. RAG de base

Une recherche, une réponse. Il faut presque toujours commencer là : cela crée un niveau de référence mesuré. Toute sophistication ultérieure doit prouver qu’elle fait mieux.

2. RAG hybride

Recherche sémantique et recherche lexicale tournent ensemble, puis leurs classements sont fusionnés. Très utile quand les utilisateurs mélangent langage naturel, références, codes erreur, noms et numéros de pièces.

3. RAG itératif ou multi-hop

Le système cherche, apprend quelque chose, construit une nouvelle requête puis cherche de nouveau. À utiliser lorsque la réponse doit être assemblée à partir de plusieurs documents ou étapes.

4. RAG correctif

Un contrôle évalue la qualité des preuves avant de générer. Si elles sont faibles, le système peut recommencer la recherche, changer de source, demander une précision ou s’abstenir.

5. Self-RAG

Self-RAG désigne une approche de recherche précise dans laquelle comportements de retrieval et de réflexion sont entraînés dans le modèle. Il vaut mieux éviter d’utiliser ce nom pour tout workflow qui critique ses propres résultats ; « retrieval auto-réflexif » est plus clair dans ce cas.

6. RAG adaptatif

Un routeur choisit le chemin selon la question. Une requête simple utilise un retrieval peu coûteux ; une question complexe peut déclencher une recherche multi-hop ou agentique. C’est utile sur un trafic hétérogène, mais beaucoup de systèmes n’en ont jamais besoin.

7. RAG agentique

La recherche devient un outil au sein d’une boucle. Le modèle choisit quoi chercher, inspecte le résultat, juge s’il est suffisant et peut appeler d’autres outils. Gardez cette flexibilité pour les chemins réellement impossibles à prévoir à l’avance.

8. RAG avec graphe

Une famille de méthodes combine retrieval et relations explicites entre entités. Elle devient pertinente pour dépendances, propriété, hiérarchies ou réseaux que la seule similarité vectorielle ne décrit pas proprement.

9. RAG multimodal

Les preuves peuvent vivre dans des schémas, tableaux, captures, scans, plans, images, audio ou vidéo. L’architecture peut associer OCR, extraction de tableaux, embeddings multimodaux et indexes spécialisés.

Et le « full context » ?

Si l’ensemble du corpus est réellement petit, on peut le mettre directement dans le contexte et supprimer l’étape de retrieval. C’est une technique légitime, parfois appelée full-context ou cache-augmented generation, mais ce n’est pas du RAG puisqu’il n’y a pas de recherche sélective.

Choisissez à partir de l’échec, pas du nom

Une architecture est bonne lorsqu’elle corrige un échec mesuré. Le comité de direction n’a pas besoin de savoir si l’équipe appelle cela « corrective RAG » ; il a besoin de savoir que le système refuse désormais d’inventer lorsqu’il ne trouve pas de preuve solide.

Les embeddings sont le mécanisme qui permet la recherche sémantique. Ils transforment un contenu en coordonnées numériques que l’ordinateur peut comparer très vite. Une fois les compromis compris, la recherche vectorielle redevient ce qu’elle est : de l’ingénierie de recherche d’information.

Qu’est-ce qu’un embedding ?

Imaginez une bibliothèque qui range les livres selon ce dont ils parlent, et non par titre ou par auteur. Deux ouvrages que personne ne classerait ensemble se retrouvent côte à côte parce qu’ils couvrent le même terrain — et « proche » devient une grandeur mesurable.

Un modèle d’embedding transforme une entrée en un vecteur de longueur fixe. Un embedding de 1 024 dimensions contient 1 024 nombres. L’entraînement fait en sorte que des contenus sémantiquement proches occupent des positions utiles les uns par rapport aux autres. Une question sur le « préavis de résiliation » peut ainsi retrouver une clause rédigée « chacune des parties peut mettre fin au contrat moyennant un préavis écrit de quatre-vingt-dix jours », même si aucun mot exact ne correspond.

L’analogie de la bibliothèque fonctionne bien : au lieu de ranger les passages par ordre alphabétique, on les range par sens. Le vecteur est l’adresse sur l’étagère.

La similarité dépend du modèle

La similarité cosinus compare l’angle entre deux vecteurs. Mathématiquement, elle va de −1 à 1, même si les embeddings réels occupent souvent une plage bien plus étroite. Zéro signifie orthogonal, pas « sans rapport » de manière universelle.

Le produit scalaire donne le même classement que le cosinus lorsque les vecteurs sont normalisés de façon appropriée. La distance euclidienne mesure la distance droite entre deux points. En pratique, utilisez la métrique recommandée par le modèle d’embedding et l’index, puis validez sur vos propres exemples.

Les dimensions échangent qualité, mémoire et vitesse

Un vecteur float32 consomme quatre octets par dimension. À 768 dimensions, cela représente environ 3 Ko avant métadonnées et surcoût d’index. Dix millions de vecteurs approchent donc 30 Go de données brutes rien que pour les coordonnées.

Davantage de dimensions peuvent conserver plus d’information, mais augmentent stockage, RAM et coût de recherche. Certains modèles modernes utilisent des représentations Matryoshka : les premières dimensions concentrent davantage de signal et l’on peut tronquer le vecteur avec une perte progressive. Ce n’est ni universel ni gratuit : testez le modèle et le ratio de troncature sur votre jeu de retrieval.

Choisir un modèle d’embedding

MTEB et les autres classements sont utiles pour établir une shortlist. Ils ne remplacent pas votre test métier. Vérifiez langues, longueur d’entrée, licence, dimensions, latence, options d’hébergement et comportement sur votre vocabulaire. Un modèle légèrement moins bien classé au niveau global peut être meilleur sur vos références techniques.

Changer de modèle d’embedding implique généralement de recalculer tout le corpus, car deux espaces vectoriels issus de modèles différents ne sont pas interchangeables. Pour 20 000 chunks, la migration est banale. Pour plusieurs dizaines de millions, elle devient un vrai projet. Le choix est une dépendance d’architecture, pas un mariage à vie.

Recherche exacte ou approximative

La recherche exacte compare la requête à tous les vecteurs candidats. La recherche ANN, pour Approximate Nearest Neighbour, évite l’essentiel de ces comparaisons et accepte une petite perte de recall mesurable en échange d’un débit beaucoup plus élevé. Il n’existe pas de seuil universel de nombre de vecteurs à partir duquel l’exact devient impossible : dimensions, matériel, filtres, volume de requêtes et cible de latence comptent autant.

HNSW : le graphe que vous rencontrerez partout

Hierarchical Navigable Small World construit un graphe à plusieurs niveaux. Les couches hautes permettent de grands sauts ; les couches basses raffinent localement. C’est l’équivalent d’un trajet autoroute → route → rue plutôt que de vérifier chaque adresse du pays.

Les implémentations exposent des réglages similaires sous des noms et valeurs par défaut différents. Trois concepts importent :

Le paramètre de largeur à la requête est particulièrement intéressant : on peut souvent l’ajuster sans reconstruire l’index. Un chemin interactif très sensible à la latence et une analyse nocturne privilégiant le recall n’ont pas besoin du même réglage. Vérifiez toujours la documentation de votre moteur ; les défauts ne sont pas portables entre pgvector, Qdrant, Weaviate, Milvus, Elasticsearch ou d’autres.

IVF et k-means

Un index IVF partitionne l’espace vectoriel en groupes, souvent avec k-means. À la requête, le moteur identifie d’abord les centroïdes les plus proches puis ne cherche que dans certaines listes. Le paramètre nprobe contrôle combien de groupes sont inspectés.

Le compromis est intuitif : sonder trop peu de groupes peut manquer un voisin pertinent situé de l’autre côté d’une frontière. Augmenter nprobe récupère du recall au prix de davantage de travail. IVF reste pertinent à grande échelle et lorsqu’on combine compression ou coût de construction faible.

Quatre réglages à reconnaître

Retrouvez large, montrez étroit

Le nombre de candidats récupérés n’est pas le nombre de passages à envoyer au modèle. Sur beaucoup de systèmes documentaires, un bon point de départ consiste à retrouver plusieurs dizaines de candidats, les reranker, puis n’envoyer qu’un petit ensemble de preuves. La valeur exacte dépend du corpus, du chunking, de la latence et du reranker.

Les seuils doivent venir de vos données

Un score cosinus de 0,75 n’a pas de signification universelle. Les distributions changent selon le modèle, le domaine et la longueur des chunks. Construisez des exemples positifs et négatifs, observez leurs scores et choisissez le seuil en fonction du compromis que vous acceptez entre abstention et recall.

Les filtres peuvent dégrader le recall

Le retrieval multi-tenant et sensible aux ACL introduit une complication : un graphe construit sur tout le corpus ne se comporte pas forcément de la même manière lorsqu’un filtre ne laisse éligible qu’une très petite sous-partie. Mesurez donc la recherche avec les filtres de production réellement appliqués. Un excellent benchmark sans ACL dit peu de choses sur votre système réel.

La recherche sémantique retrouve le sens. La recherche lexicale retrouve les mots. Les requêtes métier contiennent les deux, ce qui explique pourquoi l’hybride est un point de départ si solide pour les bases techniques, juridiques et support.

Là où le dense rate

Un embedding compresse un passage en un vecteur. C’est excellent pour les paraphrases, moins pour certains signaux exacts. « Quelle est notre politique de télétravail ? » est une requête sémantique. « E2214 », « 7.4(b) », « INV-4471 » ou une référence produit précise sont avant tout lexicaux.

BM25 et les méthodes de mots-clés restent donc très utiles. Pour les identifiants techniques, conservez aussi un champ brut ou exact afin que la tokenisation ne casse pas la chaîne que l’utilisateur cherche.

Reciprocal Rank Fusion

Les scores vectoriels et lexicaux vivent sur des échelles différentes. Les additionner directement est rarement défendable. Reciprocal Rank Fusion, ou RRF, contourne le problème en utilisant les positions dans les classements plutôt que les scores bruts.

RRF(d) = Σ 1 / (k + rangᵢ(d))

Un document correctement placé dans les deux listes peut dépasser un document adoré par un seul retriever. RRF récompense donc une forme de consensus.

La constante k contrôle à quel point les toutes premières positions dominent. La valeur 60 est une convention historique fréquente en recherche d’information, pas une loi. Sur des listes courtes, une valeur plus petite peut accentuer les écarts. Testez-la sur vos requêtes annotées au lieu d’hériter automatiquement de 60.

Fusion pondérée

L’autre approche consiste à normaliser les deux familles de scores puis à calculer une combinaison pondérée :

score(d) = α × score_semantique(d) + (1 − α) × score_lexical(d)

Ces valeurs ne sont que des points de départ. Une fusion pondérée peut battre RRF lorsque les scores sont bien calibrés, puis se dégrader si la distribution des requêtes ou le corpus change. Si vous introduisez des poids, gardez votre jeu d’évaluation versionné et rejouez-le.

Regardez d’abord la distribution réelle des requêtes

Prenez quelques centaines de recherches et classez-les en conceptuelles, identifiants exacts ou mixtes. Les systèmes support et juridiques contiennent souvent beaucoup plus de lookup exact qu’on ne l’imagine. Cette simple analyse explique parfois pourquoi un moteur dense paraît spectaculaire en démo et agaçant en production.

Transformer la requête

Query rewriting. Résoudre pronoms, raccourcis conversationnels et entités manquantes avant la recherche. « Et pour le deuxième ? » peut devenir « Quel est le délai de préavis du contrat fournisseur Thompson ? ».

Query expansion. Générer plusieurs formulations plausibles, chercher avec chacune puis fusionner. Utile lorsque le recall souffre de la façon dont les utilisateurs formulent leurs questions.

HyDE. Générer un document ou une réponse hypothétique, l’encoder puis chercher à partir de cette représentation. Cela aide sur certaines recherches en prose, mais c’est très dépendant de la tâche et mal adapté aux identifiants exacts.

Nous testons tôt un reranker lorsque le retrieval retrouve régulièrement la bonne preuve mais la place trop bas. Le premier étage et le reranker n’optimisent pas le même objectif, et c’est précisément ce qui rend la combinaison efficace.

Bi-encoder contre cross-encoder

C’est la différence entre trier une pile de CV par mots-clés et en lire réellement deux à côté de la fiche de poste. Le premier est assez rapide pour tout passer ; le second est assez juste pour décider.

Un modèle d’embedding est généralement un bi-encoder : il encode la question et le passage séparément. On peut donc pré-calculer tous les documents et chercher parmi des millions très vite. La contrepartie est qu’au moment d’encoder un passage, le modèle ne connaît pas encore la question qui sera posée.

Un cross-encoder lit la question et le passage ensemble. Il peut examiner les interactions fines entre les deux, ce qui donne souvent un meilleur classement, mais il est trop lent pour évaluer un corpus entier à chaque requête.

La chaîne naturelle est donc : retrouver rapidement un ensemble assez large, puis lire attentivement seulement cette shortlist.

Le retrieval essaie de ne rien rater ; le reranking essaie de ne pas gaspiller le contexte. Un reranker ne peut jamais récupérer un passage que le premier étage n’a pas trouvé.

Configuration de départ

Pour beaucoup de corpus documentaires, nous commençons par plusieurs dizaines de candidats, puis une sortie en unités ou petite dizaine de passages. La fourchette souvent citée « 50 à 100 en entrée, 5 à 15 en sortie » est un point de départ d’ingénierie, pas une norme. Taille des chunks, corpus, modèle de reranking, latence et difficulté des questions changent l’optimum.

Un pipeline de base très solide reste : retrieval hybride → fusion des rangs → reranking → petit ensemble de preuves → seuil de pertinence dérivé des données → génération sourcée avec droit d’abstention. Il est facile à mesurer et étonnamment difficile à battre par une architecture plus complexe si le corpus n’exige pas vraiment de graphe, multimodal ou comportement agentique.

Une mauvaise réponse finale ne vous dit pas si la recherche a échoué, si le reranker a enterré la preuve ou si le générateur a ignoré un bon contexte. Le retrieval doit être mesuré séparément.

Associez une métrique large de premier étage à une métrique de haut de classement après reranking. C’est ce duo qui permet de localiser le défaut : la preuve n’a jamais été trouvée, ou elle a été trouvée puis mal classée.

Des chiffres publiés sur Cortex

Sur une évaluation de production de Cortex, notre moteur d’intelligence support, nous avons publié notamment :

• Hit@5 : 83,3 % sur le jeu considéré. Dans ce cas, chaque question avait essentiellement une preuve de référence, d’où le choix du terme Hit@5 plutôt que Recall@5.
• Taux de citations : 95,8 %. C’est une métrique système de génération/provenance, pas une métrique de retrieval.
• Taux de fabrication mesuré : 5,0 %. Là encore, il s’agit d’une mesure système, publiée parce qu’un taux résiduel connu est plus utile qu’un risque jamais mesuré.

Ces nombres ne deviennent pas des standards universels. Ils valent pour une version de corpus, de pipeline, de modèle et de jeu de questions donnés. Pour qu’un benchmark interne soit crédible, publiez ou conservez au minimum : taille du jeu, date, corpus, modèle, configuration de retrieval/reranking et définition exacte de chaque métrique.

Commencez petit, mais versionnez

Cinquante à cent vraies questions suffisent pour démarrer des tests de régression. Elles ne suffisent pas à revendiquer une couverture complète d’un produit complexe. Tirez-les de tickets support, recherches réelles et experts métier. Un modèle peut proposer des annotations ; un humain devrait confirmer les preuves de référence. Ce jeu survivra probablement à votre embedding model, votre base vectorielle et votre LLM actuel.

Les embeddings répondent très bien à « qu’est-ce qui ressemble à cette question ? ». Ils ne remplacent pas une structure explicite lorsqu’on demande « qui dépend de quoi ? », « qui possède qui ? » ou « quelles pièces sont compatibles avec ce sous-ensemble ? ».

Taxonomie, ontologie et graphe de connaissances

Ces trois termes sont souvent mélangés. Une taxonomie classe des éléments dans une hiérarchie : produit → famille → sous-famille. Une ontologie définit des types d’entités, leurs propriétés et les relations permises entre elles. Un graphe de connaissances instancie ces concepts avec des entités et relations réelles : « pompe P12 — installée sur → banc B04 ».

Un embedding peut refléter implicitement qu’une pompe et un débit sont liés. Il ne fournit pas pour autant une arête explicite, auditable et traversable indiquant quelle pompe alimente quelle ligne.

Même nom, autre entreprise

Un dispositif de veille concurrentielle que nous avons construit remontait régulièrement des personnes et des organisations qui partageaient seulement un patronyme avec les entités suivies. La similarité ne distingue pas un homonyme d’une correspondance : la correction a été une porte de vérification d’entité fondée sur des identifiants explicites, pas un meilleur modèle d’embedding. Quatorze homonymes ont ainsi été écartés du digest d’un seul client.

Quand le graphe gagne

Relations de propriété, nomenclatures, compatibilités, dépendances de configuration, chaînes réglementaires et réseaux d’entités sont de bons candidats. Mais ne construisez pas un graphe simplement parce que le mot sonne plus avancé. Beaucoup de questions relationnelles simples se résolvent parfaitement en SQL si la donnée structurée existe déjà.

Graph RAG n’est pas une architecture unique

Le terme couvre une famille de systèmes : extraction d’entités et de relations, traversal, communautés, résumés de sous-graphes, combinaison avec vecteurs, requêtes structurées ou agents. Il faut donc demander « quel graphe, construit comment, interrogé comment, pour quelle question ? » plutôt que traiter Graph RAG comme un composant universel.

Si un LLM aide à extraire les entités ou relations, gardez provenance, règles de validation et capacité de correction. Une erreur transformée en arête de graphe peut devenir une vérité structurelle très convaincante pour tout ce qui vient après.

La base vectorielle reçoit beaucoup d’attention parce qu’elle est tangible et facile à comparer. Dans une grande partie des projets PME/ETI, elle n’est pourtant pas le facteur qui déterminera la qualité de la réponse.

Commencez par la contrainte réelle

Demandez taille du corpus, fréquence d’indexation, volume de requêtes, latence, filtres ACL, haute disponibilité, besoin multi-tenant, géographie, sauvegarde et compétences de l’équipe. Ensuite seulement choisissez le moteur.

Si vous utilisez déjà PostgreSQL et que le corpus reste raisonnable, pgvector est souvent une excellente réponse : même transaction, mêmes ACL applicatives, mêmes sauvegardes, moins de composants à opérer. Une base vectorielle dédiée devient intéressante lorsque vous avez besoin d’échelle, de filtres très riches, de réplication spécifique, d’indexation distribuée ou de fonctions que votre stack existante ne fournit pas correctement.

Ce que vous devez réellement benchmarker

Pas seulement « requêtes par seconde ». Mesurez recall avec vos filtres réels, latence p95/p99, vitesse de mise à jour, coût mémoire, récupération après incident, réindexation et comportement lorsque les ACL réduisent énormément l’espace éligible.

« Quel est le taux d’hallucination de ce modèle ? » semble être une bonne question. Elle devient vite trompeuse, car on mélange souvent plusieurs tâches, plusieurs définitions et plusieurs jeux de données dans un seul pourcentage.

Exactitude factuelle et fidélité ne sont pas la même chose

L’exactitude factuelle demande si une affirmation est vraie dans le monde. La fidélité, ou groundedness, demande si l’affirmation est réellement soutenue par les éléments fournis au modèle. Une réponse peut être vraie mais non justifiée par les documents, ou parfaitement fidèle à une source qui contient elle-même une erreur.

C’est pourquoi comparer directement un benchmark de synthèse sourcée à un benchmark de questions ouvertes et en déduire « le grounding réduit l’hallucination par 30 » n’est pas valide. Les tâches, populations de modèles et méthodes de scoring peuvent être différentes.

Les benchmarks publics montrent néanmoins deux choses utiles. Premièrement, les meilleurs modèles restent capables de produire des erreurs sur des tâches de fidélité à une source. Deuxièmement, les scores peuvent se dégrader fortement lorsque le test devient plus difficile, même pour des modèles dits de raisonnement. La conclusion défendable n’est donc pas un multiplicateur universel ; c’est que fournir des preuves inspectables change le profil de risque.

Ce qu’il faut mesurer sur un système RAG

• Fidélité. Chaque affirmation importante est-elle soutenue par les preuves fournies ?
• Exactitude factuelle. Les affirmations sont-elles vraies ?
• Précision du contexte. Les passages fournis étaient-ils réellement pertinents ?
• Recall du contexte. Le retrieval a-t-il fourni assez d’éléments pour répondre complètement ?
• Pertinence de la réponse. Le texte répond-il à la question posée ?
• Qualité de l’abstention. Le système refuse-t-il lorsqu’il n’a pas assez de preuves, sans refuser inutilement lorsqu’elles existent ?

Des frameworks comme RAGAS peuvent automatiser une partie de ces évaluations, et de petits modèles spécialisés rendent des contrôles continus abordables. Un LLM-juge reste un modèle : calibrez-le sur des annotations humaines avant de transformer son score en vérité, surtout pour des critères subjectifs ou à fort enjeu.

Zéro citation fabriquée observée sur une évaluation de production

Sur un système de veille continue livré pour un fabricant d’instrumentation en sciences de la vie, le critère d’acceptation était particulièrement strict : chaque affirmation devait remonter à une source. Le système suivait financements publics, activité concurrentielle et évolutions réglementaires dans plusieurs territoires, puis produisait une synthèse exécutive hebdomadaire. Sur le jeu d’acceptation verrouillé, 100 % des éléments étaient sourcés et aucune citation fabriquée n’a été observée.

Ce résultat ne prouve pas qu’une hallucination est mathématiquement impossible. Il montre qu’un système opérationnel peut atteindre zéro fabrication observée sur une évaluation définie lorsqu’il dispose d’un vrai chemin d’abstention. L’architecture faisait l’essentiel du travail : références conservées avec les affirmations, retrieval faible rejeté et « preuve insuffisante » accepté comme résultat légitime.

Évaluez la preuve, pas l’éloquence

Auditez la synthèse contre ce qu’elle compresse

Quand plusieurs documents deviennent un résumé de direction, vérifiez le résumé contre les sources, pas seulement sa qualité de rédaction. Nous cherchons notamment cinq familles d’erreurs : omission, fabrication, conflit de chiffre ou de date, réconciliation incorrecte de sources contradictoires et dépassement de périmètre.

Sur une mission anonymisée, cette méthode a détecté un résumé de marché qui associait un chiffre de revenus à la mauvaise place boursière, présentait deux montants incompatibles puis recommandait d’en injecter un dans un modèle de planification. Le texte paraissait parfaitement convaincant. La vérification source par source a montré que l’autorité apparente n’existait pas.

La fabrication se rattrape au contrôle, pas à la source

Sur une mission d’entrée de marché, un audit en cinq points — omissions, hallucinations, contradictions, réconciliations, périmètre — a été passé sur cent quatre-vingt-sept constats avant toute remise au client. Il a intercepté plus de trente-cinq fabrications. Le taux à la génération n’était pas nul ; le taux livré l’était. Cet écart résume à lui seul pourquoi l’étape de vérification ne se saute pas.

Ce qui réduit réellement la fabrication opérationnelle

• Ancrer les réponses importantes dans des preuves ou des outils autoritatifs.
• Exiger des identifiants de source et vérifier que la citation soutient réellement la phrase.
• Donner au modèle une voie explicite d’abstention.
• Dériver les seuils de pertinence d’exemples annotés.
• Utiliser des contrôles déterministes dès que la sortie peut être vérifiée de façon déterministe.
• Router les cas à faible confiance ou fort impact vers un humain.

Baisser la température peut réduire la variation ; cela ne garantit pas la vérité. L’objectif de production n’est pas « un modèle qui n’hallucine jamais », mais un système avec un taux d’erreur résiduel mesuré, une provenance visible et des contrôles empêchant cette erreur résiduelle de devenir silencieusement une décision.

La connaissance industrielle arrive rarement sous la forme d’un texte propre. Elle vit dans des scans, plans, tableaux de datasheets, photos, exports PDF, notes d’intervention et conversations. Un pipeline « text only » peut indexer le fichier tout en perdant silencieusement l’information qui compte.

Une source sans API

Sur un suivi de financements couvrant huit organismes publics, sept exposaient une API et un non. Plutôt que d’écarter cet organisme ou de le scraper à l’aveugle, nous avons construit pour cette seule source un chemin vérifier-puis-publier : extraire, contrôler contre l’enregistrement publié, et seulement ensuite laisser entrer dans le digest. Une source récalcitrante, c’est normal. Ce qui casse, c’est de concevoir comme si toutes se comportaient pareil.

Commencez par regarder ce que l’ingestion lit vraiment

Avant de régler les embeddings, prenez vingt documents représentatifs et inspectez le contenu extrait. Un PDF scanné peut produire une chaîne vide. Un tableau 2D peut devenir une suite de nombres séparée de ses en-têtes. Un schéma peut disparaître entièrement. Le job d’ingestion peut afficher « succès » alors que la base de connaissance contient presque rien d’exploitable.

Si une part significative des vingt documents ressort en texte incohérent, corrigez l’ingestion d’abord. Aucun reranker ne retrouve une information qui n’a jamais été indexée.

Trois technologies se cachent derrière « document AI »

Ce n’est pas une échelle de qualité où le plus général serait toujours meilleur. Un format de facture stable peut être plus fiable et moins cher avec un extracteur spécialisé et une validation déterministe qu’avec un grand modèle de vision.

Les tableaux méritent un traitement propre

Un tableau n’est pas un paragraphe avec des espaces. Le sens se trouve à l’intersection d’une ligne et d’une colonne. Sortir « 500 » sans « pression maximale », « modèle B » et « bar » détruit l’information.

Un bon pipeline conserve la structure du tableau, crée éventuellement une description textuelle pour la recherche sémantique et utilise une requête structurée lorsque l’utilisateur demande une cellule ou un calcul. C’est le même principe que donner à un LLM un accès SQL plutôt que lui demander de « lire » une capture d’écran de base de données.

Plans et photographies

Les modèles vision-language peuvent déjà extraire des informations utiles de dessins industriels : cartouches, indices de révision, notes, annotations visibles. Cela suffit parfois à rendre un fonds de plans recherchable. Interpréter de manière fiable des tolérances géométriques complexes ou des dimensions liées à la sécurité demande un niveau de validation beaucoup plus élevé et un jeu d’évaluation dédié.

Les photos terrain offrent souvent une valeur plus immédiate : lire une plaque signalétique, identifier la famille produit, retrouver l’historique de service et présenter au technicien le bon manuel. Chaque étape est bornée et mesurable.

La voix devient une vraie interface métier

Reconnaissance vocale temps réel, synthèse et modèles multimodaux à faible latence rendent la voix beaucoup plus crédible qu’il y a quelques années. Le cas d’usage intéressant n’est pas « un chatbot qui parle » pour le spectacle. C’est la capture et l’action là où taper est pénible : technicien qui marche sur site, opérateur avec des gants, passation de maintenance, appel support, inspection mains libres.

Dans les entreprises où la connaissance la plus rare est détenue par quelques ingénieurs expérimentés, des conversations enregistrées et transcrites peuvent aussi alimenter un programme de capitalisation. Consentement, durée de conservation et accès doivent être traités comme pour tout autre dossier métier.

Capacités vérifiées le 20 août 2026 · les modèles voix temps réel et intégrations téléphoniques évoluent rapidement.

Deux architectures de production

Voix en cascade. La parole devient texte, le texte passe dans votre stack LLM/outils habituelle, puis la réponse redevient audio. C’est modulaire, observable et facile à brancher sur un agent textuel existant. Le prix à payer est une latence supplémentaire et la perte d’une partie du ton, des interruptions et signaux non textuels.

Voix native temps réel. L’audio reste dans une session multimodale à faible latence. Le modèle peut raisonner, appeler des outils et répondre alors que la conversation se déroule encore. L’expérience est plus naturelle et gère mieux les interruptions, mais l’observabilité et le contrôle doivent être conçus explicitement.

Les difficultés sont conversationnelles autant qu’acoustiques

• Détection de tour et interruption. Le système doit savoir quand la personne a fini et cesser de parler proprement lorsqu’elle le coupe.
• Noms, nombres et identifiants. Numéros de série, adresses mail, codes pièces et montants doivent être confirmés ; un caractère mal entendu peut déclencher la mauvaise action.
• Bruit et accents. Atelier, véhicule, ligne téléphonique médiocre et conversations multilingues doivent être dans le jeu d’évaluation dès le départ.
• Latence des outils. Cinq secondes d’ERP paraissent bien plus longues à l’oral qu’en chat. Il faut accuser réception ou donner un statut plutôt que créer du silence.
• Passage à l’humain. Le transfert doit transmettre conversation, contexte et transcript sans obliger le client à recommencer.

Conservez en production un transcript ou un journal structuré des événements même si l’interaction est speech-to-speech. Vous obtenez ainsi quelque chose de recherchable, évalu-able, caviardable et auditable. Les règles d’enregistrement s’appliquent toujours, et la voix fait parfois émerger des données personnelles plus spontanément qu’un formulaire écrit.

Évaluez l’extraction champ par champ

Créez un jeu annoté de documents représentatifs et mesurez l’exactitude par champ. Mesurez surtout une seconde erreur : à quelle fréquence le système invente-t-il une valeur lorsque le champ est réellement vide ? Pour les extractions importantes, renvoyez la provenance avec chaque valeur : page, cellule, région ou span source. La vérification devient alors beaucoup plus rapide.

La génération de texte devient de l’IA opérationnelle lorsque le modèle peut demander une action : interroger une base, exécuter du code, lire un ERP, créer un ticket ou préparer un message pour validation. L’ingénierie importante se trouve entre la demande du modèle et le monde réel.

Comment fonctionne un appel d’outil

L’application décrit au modèle les outils disponibles, leur fonction et les arguments qu’ils acceptent. Le modèle peut alors produire une demande structurée du type : appeler get_invoice avec id=INV-4471. Le runtime hôte vérifie que la demande est valide et autorisée, exécute éventuellement la fonction, puis renvoie le résultat au modèle.

Le modèle n’obtient pas magiquement les identifiants de la base parce qu’il a généré un tool call. L’exécution appartient au système qui l’entoure. C’est là que doivent vivre authentification, autorisation, validation des paramètres, gestion des secrets et approbation humaine.

MCP : une interface commune pour outils et contexte

Le Model Context Protocol, lancé par Anthropic en 2024 puis placé sous la gouvernance de l’Agentic AI Foundation de la Linux Foundation, standardise la manière dont des clients compatibles découvrent et utilisent des outils et ressources externes. Son adoption par les fournisseurs de modèles, les outils développeurs et les logiciels d’entreprise en a fait l’un des principaux standards d’interopérabilité de l’écosystème agentique.

A2A, initié par Google puis lui aussi placé sous gouvernance Linux Foundation, traite une frontière différente : la découverte et la communication entre agents. Une formule simple : MCP relie un client IA à des outils et des données ; A2A traite l’interopérabilité agent à agent.

MCP ne remplace pas la sécurité classique

Une étude de mesure publiée en 2026 a identifié 7 973 serveurs MCP distants actifs et observé que 40,55 % exposaient des outils sans authentification. Sur le sous-ensemble OAuth testable, les chercheurs ont également relevé de nombreux défauts d’implémentation. La conclusion n’est pas « MCP est dangereux ». Elle est plus banale et plus importante : une adoption rapide n’exonère jamais authentification, périmètre réseau, moindre privilège et vérification de provenance du serveur.

Le harness : l’environnement qui transforme une intention en action

Le harness, ou couche d’exécution, regroupe les outils, credentials, sandbox, permissions, validateurs, budgets, logs et règles qui déterminent ce que le modèle peut réellement faire.

Imaginez un sous-traitant très compétent qui arrive sur un site industriel. Le modèle est le sous-traitant. Le harness, c’est l’accueil sécurité, le badge, les portes fermées, le permis de travail, les instruments de mesure et la signature finale. La compétence compte ; le cadre détermine ce que vous pouvez lui laisser toucher.

Des règles de production qui vieillissent bien

• Préférez peu d’outils, bien distincts. Des fonctions qui se chevauchent rendent le choix ambigu et chaque description consomme du contexte.
• Retournez juste ce qui est utile à la prochaine décision. Une réponse API de 300 lignes est rarement un bon contexte. Transformez-la en quelques champs pertinents.
• Appliquez le moindre privilège par outil. Lecture par défaut, écriture limitée, validation explicite pour les actions irréversibles ou à fort impact.
• Sandboxez le code généré. Isolez l’exécution, contrôlez l’egress réseau et ne montez pas des secrets dont la tâche n’a pas besoin.
• Rendez les échecs explicites. « Aucune facture trouvée pour INV-4471 » est un résultat utile. Une réponse vide pousse le modèle à combler le manque.
• Vérifiez le serveur ou le connecteur lui-même. Descriptions d’outils, packages MCP et connecteurs font partie de votre supply chain. Épinglez les versions, examinez les permissions et surveillez les changements.

Un humain peut tolérer une phrase de trop. Une API, non. Dès qu’une sortie de modèle alimente un logiciel plutôt qu’un lecteur, la structure devient un contrat d’ingénierie.

Trois niveaux de contrôle

Le décodage contraint par schéma peut empêcher des noms de champs impossibles ou certains mauvais types parce que ces continuations sont interdites pendant la génération. C’est un progrès majeur par rapport à « merci de respecter ce format ». Cela ne rend pas vraie une date de facture mal lue.

Concevez le schéma pour le modèle et pour le workflow

• Restez peu profond. Des structures très imbriquées augmentent les relations que le modèle doit maintenir.
• Utilisez des enums pour les choix fermés. Ils réduisent l’ambiguïté et simplifient le traitement aval.
• Prévoyez explicitement l’absence de valeur. « non trouvé » est plus sûr que forcer chaque champ à être rempli.
• Retournez la preuve. Page, span source, identifiant d’enregistrement ou citation permet au système suivant de vérifier.
• Nommez les champs sémantiquement. montant_net_eur donne plus de contexte que value_3.

Quatre états, pas « valide ou invalide »

La même mission classait chaque livrable dans l’un de quatre états avant remise : déployable tel quel, déployable après vérification, modèle réutilisable seulement, ou bloqué par une contrainte NDA. Trente-neuf éléments sur soixante-deux passaient immédiatement ; les autres étaient orientés, pas rejetés. Un simple valide / invalide aurait jeté l’essentiel du travail.

Générer, valider, réparer, escalader

1. Générer contre le schéma.
2. Valider la structure et les règles métier déterministes. Le total correspond-il aux lignes ? La référence existe-t-elle au catalogue ? La date est-elle plausible ?
3. Réparer en renvoyant la sortie rejetée et l’erreur précise pour un nombre limité de tentatives.
4. Escalader lorsque le budget de correction est épuisé ou que l’impact dépasse le seuil d’automatisation.

Une file d’exceptions est le signe d’un système contrôlé, pas d’un échec. Un workflow qui « renvoie toujours quelque chose » finira tôt ou tard par renvoyer quelque chose de faux sans vous prévenir.

Les bonnes pratiques d’intégration restent valables

Idempotence pour éviter qu’un retry poste deux fois une commande, timeouts, circuit breakers, prompts et schémas versionnés, contract tests sur un jeu de référence après changement de modèle ou de prompt. Rien de cela n’est exotique. Le composant amont est probabiliste ; le logiciel qui l’entoure ne doit pas l’être davantage que nécessaire.

La définition utile d’un agent tient en une phrase : le modèle peut utiliser des outils, observer ce qui s’est passé et décider quoi faire ensuite. Ce qui le définit est la boucle, pas l’étiquette commerciale.

Workflow ou agent ?

Si votre code impose la séquence et que le modèle remplit seulement certaines étapes, vous avez un workflow enrichi par l’IA. C’est souvent exactement ce qu’il faut : prévisible, testable et économique. Si le modèle choisit l’action suivante en fonction de ce qu’il vient de découvrir, vous avez une boucle agentique.

La plupart des agents suivent une variante de : rassembler le contexte → décider → agir → observer → vérifier → recommencer.

Trois questions séparent la démo du système de production

Comment sait-il que la tâche est terminée ?

Ne vous reposez pas uniquement sur le modèle de travail qui se demande s’il a fini. Utilisez dès que possible une condition externe : tests passés, schéma valide, état de base de données, checklist explicite ou vérificateur indépendant qui ne peut pas modifier le résultat.

Qu’est-ce qui l’arrête ?

Fixez des plafonds de nombre d’étapes, temps réel, tokens, appels d’outils et dépense. Un agent qui ne progresse plus doit tomber dans un état visible et escaladable, pas continuer jusqu’à épuiser le budget.

Où vit la progression ?

Une tâche longue a besoin d’un état durable hors de la fenêtre du modèle. Enregistrez étapes terminées, décisions, artefacts, erreurs et prochaine action prévue afin qu’un nouveau processus, une nouvelle session ou un humain puisse reprendre après un crash ou un reset de contexte.

Exécution durable : la couche souvent oubliée

Un agent sérieux doit survivre à une panne logicielle ordinaire. Cela implique checkpoints, actions idempotentes, files, verrous ou leases si nécessaire, retries bornés et règles de récupération claires.

• Checkpoint avant et après les actions importantes. Avant de relancer une étape, il faut savoir si le bon de commande a déjà été créé.
• Rendez les écritures idempotentes. Rejouer la même demande ne doit pas créer deux fois la même facture.
• Prévoyez des actions compensatoires. Si l’étape 4 échoue après le commit de l’étape 3, sachez annuler ou escalader.
• Persistez un état compact de la tâche. Un transcript de 200 000 tokens ne doit pas être l’unique mémoire opérationnelle.
• Prévoyez un kill switch. Les opérateurs doivent pouvoir bloquer les nouvelles actions tout en conservant les traces nécessaires au diagnostic.

L’analogie est celle d’une relève d’équipe. Un nouvel ingénieur doit pouvoir reprendre grâce à un état écrit, pas en héritant du cerveau de la personne précédente.

Quand ne pas construire un agent

Une architecture agentique augmente latence, tokens et difficulté de débogage. Utilisez-la pour acheter une flexibilité dont vous avez réellement besoin, pas parce que « agent » paraît plus avancé que « workflow ».

L’autonomie n’est pas binaire. Les bonnes questions sont : que le système peut-il décider, que peut-il exécuter, quelles limites s’appliquent et qui remarque qu’un résultat est mauvais ?

Pipeline sans surveillance, envoi sous contrôle

Un système de veille hebdomadaire que nous opérons exécute toute sa collecte et sa synthèse sans surveillance le dimanche, puis s’arrête. Une prévisualisation part vers une personne nommée, qui répond pour approuver, et seulement alors l’envoi du lundi 8h00 se déclenche. Le travail coûteux est autonome. L’étape irréversible ne l’est pas.

Une échelle d’autonomie

Choisissez le niveau avec un test de rayon d’impact : quel est le pire résultat crédible, à quelle vitesse le détectez-vous et pouvez-vous l’annuler ? La qualité du modèle ne répond pas à ces questions.

Les systèmes multi-agents

Un coordinateur peut distribuer le travail à plusieurs workers disposant d’outils ou de contextes différents. Le bénéfice le plus fréquent n’est pas une « personnalité spécialisée » magique, mais l’isolation du contexte. Cinq workers peuvent chacun lire vingt documents et retourner cinq synthèses courtes ; le coordinateur travaille alors sur cinq résultats, pas sur cent fichiers bruts.

Le coût se multiplie également : tokens, latence, recherche dupliquée, contradictions et traces plus complexes. Commencez avec un seul agent bien outillé. Ajoutez plusieurs agents lorsqu’une décomposition ou une isolation produit un gain mesuré.

Les agents qui utilisent un ordinateur

Certains agents peuvent manipuler une interface graphique à partir de captures d’écran, d’événements souris et clavier. C’est utile lorsqu’un logiciel n’offre pas d’API convenable, mais l’interface graphique est une surface d’intégration fragile : boutons déplacés, pop-up inattendue, session expirée, état visuel ambigu.

API d’abord, GUI ensuite. Lorsque le computer use est nécessaire, vérifiez l’état après chaque action importante, limitez fortement les permissions et exigez une validation avant toute étape irréversible. Une interface doit être traitée comme un état externe non fiable, pas comme une fonction déterministe.

Le computer use est surtout un successeur plus flexible de la vieille automatisation d’écran. Le modèle peut reconnaître qu’un bouton a bougé, mais il reste exposé au contenu affiché, y compris du texte malveillant qu’il pourrait interpréter comme une instruction.

Là où il peut être pertinent

• ERP legacy, logiciel de laboratoire ou application desktop sans API exploitable.
• Workflow de faible volume déjà exécuté par un humain via une interface relativement stable.
• Travail transverse sur plusieurs applications où maintenir plusieurs intégrations spécifiques coûterait davantage qu’un computer use supervisé.

Contrôles de production

• Isolez la session. Profil navigateur dédié, VM ou sandbox, pas le poste privilégié d’un salarié.
• Contraignez destinations et credentials. Uniquement les sites, fichiers et comptes nécessaires.
• Validez les actions conséquentes. Paiements, messages externes, suppression de données, changement de permissions ou formulaires engageants ne doivent pas dépendre d’un pixel aperçu au bon endroit.
• Vérifiez l’état après l’action. Lisez la confirmation, interrogez le système de référence si possible et rendez les écritures idempotentes.
• Conservez la trace. Captures, actions et résultats jouent le même rôle que les logs de tool calls.

L’orchestration : la plomberie derrière l’intelligence

• Routage. Envoyer les cas simples à un modèle moins cher et réserver la capacité frontier aux tâches qui en ont besoin. Mesurez le gain au lieu de supposer un pourcentage.
• État. Persister la progression pour qu’un restart ne perde pas une heure de travail.
• Retries et fallback. Gérer rate limits, erreurs transitoires et indisponibilité sans dupliquer les effets de bord.
• Observabilité. Tracer appels modèle, outils, retrieval, décisions, latence, tokens, coût et résultat final.
• Cache. Réutiliser les préfixes statiques et résultats intermédiaires lorsque l’architecture le permet.
• Évaluation. Enregistrer si la tâche est réellement terminée correctement, pas seulement si chaque API a répondu 200.

LangGraph, SDK fournisseurs, moteurs de workflow comme n8n ou code applicatif classique peuvent implémenter ces motifs. Les frameworks changent vite ; les exigences ci-dessus beaucoup moins.

Les noms de modèles vieillissent vite. Les catégories de charge de travail beaucoup moins. Choisissez le modèle le plus petit et le moins cher qui franchit un seuil de qualité mesuré, puis gardez le système suffisamment portable pour changer plus tard.

Quatre niveaux utiles

Une application mature peut utiliser plusieurs niveaux dans la même requête : petit routeur, modèle d’embedding spécialisé, reranker puis modèle plus fort pour la synthèse difficile. Envoyer chaque appel au plus gros modèle est une architecture simple, pas forcément une bonne architecture.

Fermé contre poids ouverts

Les modèles fermés s’utilisent via un fournisseur ou une plateforme cloud. Vous évitez le serving, bénéficiez de contrats enterprise et accédez souvent le plus vite aux capacités frontier. En échange, vous acceptez dépendance fournisseur, tarification à l’usage et conditions de traitement négociées.

Les modèles à poids ouverts rendent leurs paramètres entraînés téléchargeables sous une licence donnée. Vous pouvez les auto-héberger, louer du compute ou appeler un tiers qui héberge exactement ces poids. « Poids ouverts » ne signifie donc ni open source complet, ni usage sans restriction, ni auto-hébergement.

Poids ouverts est une propriété du modèle, pas une décision d’hébergement

Le même modèle peut être consommé via une API serverless et ne jamais toucher votre GPU, ou fonctionner totalement hors ligne sur votre infrastructure. Les implications de coût, de confidentialité, de continuité et de souveraineté sont alors très différentes, alors que le fichier de poids est identique.

Ne réduisez pas le choix au classement benchmark

En 2026, les modèles ouverts se sont beaucoup rapprochés du frontier fermé sur certains benchmarks de code, raisonnement et agents. L’écart dépend pourtant de la tâche et bouge trop vite pour être résumé honnêtement en « X mois de retard ». Sur extraction, classification, RAG grounded ou rédaction structurée, des modèles ouverts peuvent être largement suffisants. Sur des séquences agentiques longues où les erreurs se cumulent, le meilleur modèle fermé peut encore rentabiliser son surcoût.

Le fine-tuning est un outil, pas la réponse par défaut

Il peut enseigner un comportement répétable, un format, un style métier ou un motif de classification lorsque vous disposez de bons exemples. Il reste généralement un mauvais moyen de maintenir à jour des faits qui changent. Pour la connaissance, retrieval ou outils. Pour le comportement, fine-tuning seulement après avoir montré que prompts et exemples ne suffisent pas.

Un processus de sélection qui survivra au prochain trimestre

1. Collectez 20 à 50 tâches représentatives, puis enrichissez le jeu avec les échecs réels.
2. Définissez ce qu’est une réponse acceptable avant de regarder les modèles.
3. Testez plusieurs niveaux et, si possible, plusieurs fournisseurs.
4. Notez d’abord exactitude et réussite de tâche, puis coût, latence et modes de panne.
5. Choisissez l’option la moins chère qui franchit le seuil de qualité.
6. Versionnez prompts, contrats d’outils et évaluations afin qu’un swap de modèle soit un changement d’ingénierie, pas un acte de foi.

Le changement stratégique de 2026 n’est pas seulement que les modèles à poids ouverts coûtent moins cher. Plusieurs laboratoires chinois publient désormais des familles suffisamment proches du frontier pour que les entreprises européennes et britanniques puissent arbitrer réellement entre capacité, prix, contrôle et indépendance opérationnelle.

Le marché a bougé très vite

DeepSeek, Qwen d’Alibaba, Moonshot AI, Zhipu AI et MiniMax ont tous fait progresser de grandes familles ouvertes ou librement déployables en 2026. Le papier de Kimi K3 décrit par exemple un modèle MoE de 2,8 billions de paramètres au total, dont 104 milliards actifs, multimodal natif et fenêtre de contexte d’un million de tokens.

Il serait trompeur d’en déduire une phrase permanente du type « l’open est à quatre mois du frontier ». Versions, licences, endpoints et prix peuvent changer en quelques semaines. Utilisez cette section pour comprendre les forces économiques, puis vérifiez la table en direct avant tout achat.

Pourquoi publier les poids ?

• Commoditiser un complément. Un acteur qui gagne de l’argent sur cloud, compute, intégration ou écosystème peut préférer que le modèle devienne abondant.
• Acheter de la distribution. Des poids publiés se diffusent via Hugging Face, fine-tunes, outils développeurs et hébergeurs tiers bien plus facilement qu’une API étrangère peu adoptée.
• Compétition par l’efficacité. Les contraintes sur les accélérateurs poussent l’industrie à travailler sparsité, précision numérique, attention et serving. Il faut rester prudent sur la causalité exacte, mais l’effort d’efficacité est visible.
• Influencer les standards et défauts. Les modèles autour desquels les développeurs construisent finissent par peser sur les APIs et stacks de déploiement.
• S’inscrire dans une stratégie industrielle plus large. Politique d’État, économie du cloud et économie des modèles ne sont pas indépendantes.

La leçon de continuité de juin 2026

Le 12 juin 2026, les États-Unis ont imposé des restrictions d’exportation sur Anthropic Fable 5 et Mythos 5, forçant Anthropic à suspendre temporairement l’accès faute de pouvoir vérifier de manière fiable la nationalité des utilisateurs. Les restrictions ont été levées le 30 juin et Fable 5 a été rétabli globalement le 1er juillet. L’interruption n’a duré que quelques semaines, mais elle illustre une dépendance réelle : l’accès à un service frontier fermé peut changer à la suite d’une décision juridique ou géopolitique extérieure à votre contrat.

Des poids déjà téléchargés et exploités sur une infrastructure que vous contrôlez ne peuvent pas être retirés à distance de la même façon. Cela ne veut pas dire que chaque entreprise doit auto-héberger. Cela veut dire qu’une dépendance IA critique mérite la même analyse de continuité qu’un autre fournisseur essentiel, avec un fallback testé lorsque l’impact le justifie.

Mixture of Experts : énorme sur disque, partiellement actif à chaque token

Un modèle dense mobilise l’essentiel de ses paramètres pour chaque token généré. Un Mixture of Experts, ou MoE, route chaque token vers seulement une partie du réseau. Imaginez un hôpital avec des centaines de spécialistes disponibles, mais seulement quelques-uns consultés pour un patient donné.

Il faut donc distinguer paramètres totaux, qui pèsent fortement sur la mémoire nécessaire pour contenir les poids, et paramètres actifs, qui influencent une grande partie du calcul par token. Routage, attention, bande passante mémoire et logiciel de serving comptent également. Dire qu’un MoE de 284B/13B « tourne comme un dense 13B » serait donc trop simpliste.

Pourquoi les prix peuvent être si bas

Sparsité MoE, précision réduite, attention efficace et meilleurs serveurs diminuent le calcul par token. Des hébergeurs tiers se font ensuite concurrence pour servir les mêmes poids téléchargeables. Un déploiement interne ne gagne pas automatiquement cette bataille économique si vos GPU restent à moitié vides alors qu’un hébergeur mutualise des milliers de clients.

Instantané daté du marché

Vérifié le 20 août 2026 · selon fournisseur et route d’hébergement · à revalider avant toute offre commerciale.

La ligne DeepSeek a dû être modifiée entre deux versions de ce guide : V4 Flash avait été lancé avec $0,14 en entrée cache-miss et $0,28 en sortie, puis DeepSeek a introduit une tarification heures pleines / creuses applicable le 17 août 2026, quelques jours avant publication. C’est exactement la raison pour laquelle toute donnée de prix doit porter une date.

Poids ouverts ne règle pas à lui seul la gouvernance

Séparez l’origine des poids de l’endroit où vont vos données. Appeler une API hébergée signifie que prompts et réponses sont traités par ce fournisseur selon son contrat et sa juridiction. Télécharger les mêmes poids et les exécuter sur votre infrastructure n’envoie pas vos prompts au créateur du modèle simplement à cause de sa nationalité.

En revanche, l’auto-hébergement soulève d’autres questions : licence, provenance de la supply chain, vulnérabilités, comportement du modèle, mises à jour et évaluation. Conservez dans l’inventaire IA le modèle, sa version, la licence, la source, le checksum et le propriétaire interne.

Les benchmarks permettent de comparer une capacité dans un cadre contrôlé. Ils deviennent dangereux lorsqu’un score de leaderboard est traité comme une prévision directe de votre workflow de production.

Pourquoi le score a besoin de contexte

• Contamination. Des tâches publiques peuvent apparaître dans l’entraînement ou des datasets dérivés. Les jeux d’évaluation eux-mêmes contiennent parfois des items ambigus ou cassés.
• Scaffolding. Un bon harness, des retries et un contexte bien préparé peuvent faire fortement progresser le même modèle. Parfois vous benchmarkez le système, pas seulement le modèle.
• Saturation. Lorsque les leaders sont proches du plafond, un petit écart de score transporte peu d’information utile.
• Méthodologie. Un essai unique, best-of-N, budgets de raisonnement ou accès à des outils ne sont pas directement comparables.
• Dérive de production. Vos données, APIs, utilisateurs et permissions changent ; le benchmark est une photo.

Le point de comparaison était une personne, pas un benchmark

Pour un système de tri des demandes de support, les chiffres qui comptaient étaient une justesse de routage supérieure à quatre-vingt-dix pour cent et un temps de routage inférieur à deux minutes, mesurés contre un dirigeant qui consacrait plus de trente minutes à trier chaque ticket lui-même. Aucun classement de modèles n’aurait dit si cela fonctionnait.

Évaluez le résultat final du travail

• Réussite de la tâche. Le travail demandé est-il terminé correctement ?
• Contrôles déterministes. Tests, règles métier et calculs passent-ils ?
• Taux de correction humaine. À quelle fréquence un humain doit-il modifier le résultat avant usage ?
• Exactitude et fidélité. Les affirmations importantes sont-elles vraies et sourcées ?
• Latence et coût par tâche terminée. Un token moins cher peut produire un workflow plus cher s’il déclenche davantage de retries.
• Échecs de permission et sécurité. L’agent tente-t-il des actions hors de son périmètre ?
• Régression par version. Chaque changement de modèle, prompt, outil ou retrieval doit pouvoir être relié à une évaluation.

Utilisez les benchmarks publics pour choisir qui mérite un test. Utilisez vos propres tâches pour choisir qui mérite la production. Le jeu d’évaluation interne, enrichi de chaque cas difficile et chaque incident, devient l’un des actifs les plus durables de votre programme IA.

La plupart des produits d’IA finissent par envoyer un contexte à un service de modèle puis récupérer une sortie. Comprendre cette transaction rend prix, architecture et différenciation fournisseur beaucoup plus faciles à juger.

La transaction

Une API permet à un logiciel de demander un service à un autre. Une requête vers un modèle contient généralement le modèle choisi, des instructions ou messages, la définition des outils, des contraintes de sortie et des paramètres de génération. Le fournisseur renvoie du contenu, des tool calls ou des données structurées, souvent avec les informations d’usage.

La gestion d’état varie selon l’API. Certains appels sont entièrement autonomes ; certaines plateformes peuvent stocker conversations, fichiers, préfixes mis en cache ou autres états côté serveur. Le principe durable reste celui du contexte engineering : le modèle ne peut raisonner que sur ce que l’inférence courante rend disponible, quelle que soit la façon dont la plateforme l’a assemblé.

# Exemple volontairement simplifié
POST /v1/responses
{
  "model": "example-model",
  "input": "Résume ce contrat : ...",
  "max_output_tokens": 1000
}

# Métadonnées d’usage typiques
{
  "input_tokens": 8412,
  "output_tokens": 316
}

Les tokens sont le compteur de base

Les fournisseurs facturent en général séparément entrée et sortie par million de tokens. La sortie coûte souvent plusieurs fois plus cher parce que générer séquentiellement est plus coûteux que traiter un préfixe existant. Reasoning tokens, cache et batch modifient fortement le coût effectif.

À titre d’ordre de grandeur très approximatif, un million de tokens de texte anglais représente environ 750 000 mots ; le français varie. Une requête RAG métier peut consommer plusieurs milliers ou dizaines de milliers de tokens en entrée pour quelques centaines en sortie. Un appel paraît donc peu coûteux, alors que le volume, les retries et les boucles agentiques font vite monter la facture.

Ordre de grandeur daté, pas devis

Vérifié le 20 août 2026 · un prix peut changer sans changement de version du modèle.

Vérifiez toujours la page live avant de budgéter. Ce guide lui-même a dû modifier la ligne DeepSeek entre rédaction et publication après un changement tarifaire le 17 août 2026.

Cache, batch et routage changent l’économie

Les préfixes statiques répétés peuvent être mis en cache à un tarif fortement réduit. Les endpoints batch non urgents bénéficient parfois de remises importantes. Un routeur peut envoyer les tâches simples vers un modèle moins cher. L’unité utile n’est donc pas « dollars par million de tokens », mais coût par tâche métier correctement terminée.

Qu’appelle-t-on un wrapper ?

À l’extrême le plus mince, un wrapper est une interface, un prompt et un appel à un modèle. Le terme devient beaucoup moins pertinent lorsque le produit ajoute véritablement intégration, workflow, retrieval, permissions, audit, traitement de données ou évaluation.

Le test de substitution

Posez la question : un utilisateur compétent peut-il obtenir environ 80 % de la valeur en collant un bon prompt dans un assistant généraliste ? Si oui, la différenciation est faible. Si le produit dépend de données propriétaires, d’intégrations profondes, d’exécution multi-étapes, de contrôles de conformité ou d’une boucle de feedback opérationnelle, l’appel modèle n’est qu’un composant.

Pourquoi les wrappers minces subissent une pression économique

Les produits AI-native portent souvent une marge brute plus faible que le logiciel traditionnel parce que l’inférence reste un coût variable. Certaines analyses de marché placent des entreprises applicatives IA autour de 50–60 % de marge brute contre environ 70–90 % pour des logiciels traditionnels, avec une dispersion très large. Le risque stratégique plus important est la substituabilité : si l’actif propriétaire est seulement un prompt, un fournisseur de fondation peut intégrer la fonction et un concurrent peut la reproduire rapidement.

La défense vient de la donnée, du workflow, des intégrations, de la distribution, de la confiance et de l’apprentissage accumulé.

Questions à poser à un fournisseur

• Que se passe-t-il si le modèle de base est repricé, retiré ou indisponible ?
• Que fournissez-vous que je ne peux pas reproduire dans un assistant généraliste ?
• Montrez-moi votre méthodologie d’évaluation, pas seulement la démo.
• Où nos données sont-elles traitées et que dit le contrat ?
• Quel est le coût par tâche terminée à notre volume ?

Un wrapper interne peut être exactement la bonne solution. Un outil interne n’a pas besoin d’un moat de venture capital ; il doit économiser du temps, améliorer la qualité ou réduire le risque.

Là où la valeur est réellement venue

Sur une mission Ascentis AI auprès d’un fabricant de calorimétrie de sécurité batterie, un conseiller commercial privé dopé à l’IA est passé du MVP à la production en huit semaines, avec un retour estimé autour de 5× et un payback d’environ deux mois et demi. Sur l’activité support d’un fabricant d’équipements de dépôt de couches minces, le triage automatique est passé d’environ trente minutes à moins de deux minutes par cas, à plus de 90 % de précision.

L’API modèle n’était pas la difficulté. Le premier résultat dépendait de battlecards confidentielles et de stratégie de prix. Le second de refonte de processus, connaissance métier et intégration. C’est la frontière pratique entre « wrapper d’API » et système dont l’entreprise dépend.

Le déploiement n’est pas un choix moral entre « cloud » et « local ». C’est un arbitrage entre capacité, coût, contrôle, souveraineté, latence et charge d’exploitation. Tout ramener à « nos données sont-elles sensibles ? » conduit à de mauvaises décisions.

Quatre mots qu’il faut arrêter d’utiliser comme synonymes

Résidence des données : où les données sont physiquement traitées ou stockées.

Localisation : obligation contractuelle, politique ou légale de maintenir les données dans un territoire ou un environnement donné.

Juridiction : quels régimes juridiques et pouvoirs d’accès gouvernementaux peuvent atteindre le fournisseur ou les données.

Souveraineté : jusqu’où vous pouvez opérer, gouverner et continuer la capacité critique sous des contrôles que vous maîtrisez, plutôt que sous des contrôles qu’un fournisseur ou un État étranger peut changer.

Une charge peut être résidente en Europe sans être souveraine. Elle peut également être souveraine sans être physiquement dans vos bureaux, par exemple si vous contrôlez modèles, clés, déploiement et environnement d’exploitation dans un datacentre européen sous une structure juridique adaptée. Définissez l’exigence avant de choisir l’étiquette d’hébergement.

L’économie de l’auto-hébergement

Diviser le prix d’un GPU par son débit théorique fait presque toujours paraître l’auto-hébergement extraordinairement bon marché. Le calcul suppose souvent forte utilisation, batches idéaux et coût d’ingénierie nul. Le trafic métier est rarement aussi discipliné.

La comparaison honnête est souvent auto-hébergement d’un modèle ouvert contre hébergeur spécialisé du même modèle, et non contre l’API frontier la plus chère. À faible utilisation ou charge irrégulière, l’infrastructure mutualisée gagne fréquemment parce que le fournisseur garde son matériel occupé avec plusieurs clients.

Ajoutez les personnes : drivers, serveur d’inférence, upgrades, monitoring, sécurité, capacity planning, sauvegarde, astreinte et réévaluation après changement de modèle.

La contrainte décisive est souvent contractuelle, pas technique

Deux de nos déploiements auto-hébergés n’ont pas été choisis pour la latence ou le coût unitaire. Sur un conseiller commercial, le corpus était fait de battle cards, d’analyses concurrentielles et de logiques de prix confidentielles qui ne pouvaient tout simplement pas transiter par une API tierce. Sur un système de veille, la synthèse tourne sur un hôte résident au Royaume-Uni afin qu’aucune API de modèle tierce ne se trouve dans le chemin de données de production. Dans les deux cas, une piste d’audit des prompts et des réponses, interrogeable, faisait partie du besoin, pas du confort.

Quand l’auto-hébergement est généralement justifié

• Utilisation soutenue et prévisible avec TCO mesuré inférieur aux alternatives hébergées.
• Environnement air-gapped ou déconnecté.
• Règles contractuelles ou sécurité interdisant l’envoi de certaines données à un processeur externe.
• Exigence de souveraineté comprenant disponibilité du modèle et cycle de déploiement.
• Personnalisation ou matériel spécialisé rendant une API générique mal adaptée.

Inférence on-device

Téléphones, laptops, véhicules et équipements industriels disposent de plus en plus d’accélérateurs capables d’une inférence locale utile. Le on-device est intéressant sans réseau, lorsque la latence aller-retour est trop élevée, lorsque les données brutes ne doivent pas sortir ou lorsque des milliers de petites inférences locales seraient absurdes à centraliser.

L’architecture mature est souvent hybride : classifier, transcrire ou filtrer localement, puis escalader le raisonnement difficile vers un modèle central seulement si nécessaire.

L’IA souveraine inclut la chaîne d’approvisionnement logicielle

Exécuter les poids localement n’achève pas la discussion. Le chemin d’inférence dépend également du tokenizer et de sa configuration, de l’image conteneur, du serveur d’inférence, des drivers GPU et de CUDA, des packages Python, des modèles d’embedding et de reranking, de l’OCR, des serveurs MCP, du registre de modèles, du mécanisme de mise à jour et souvent de télémétrie.

Une supply chain souveraine en pratique

• Enregistrez la provenance. Famille, version exacte, licence, source, checksum ou signature, propriétaire, date d’approbation.
• Épinglez tout ce qui s’exécute. Révision du modèle, digest de conteneur, lockfiles, version du serveur. « latest » n’est pas une version de production.
• Miroirez les artefacts critiques. Poids, conteneurs et packages approuvés dans un registre interne afin que la production ne dépende pas d’un hub public accessible demain.
• Contrôlez egress et télémétrie. Sachez quels composants appellent l’extérieur pour licence, crash reporting, métriques, update check ou téléchargement.
• Promouvez les mises à jour, ne les absorbez pas. Nouvelle version = scan, revue de licence, évaluation puis promotion. Gardez un rollback testé.
• Incluez les modèles secondaires et outils. Embeddings, rerankers, OCR, guardrails, navigateurs et serveurs MCP peuvent tous modifier le comportement ou exposer de la donnée.

L’air-gap réduit l’exposition à l’exécution, mais ne prouve pas que les artefacts importés sont sûrs. Un environnement déconnecté a toujours besoin d’une chaîne contrôlée de média, provenance, scan et promotion.

Vous n’avez pas besoin de devenir ingénieur GPU pour acheter correctement de l’IA. Vous avez besoin d’assez de vocabulaire pour challenger des chiffres de capacité optimistes et comprendre pourquoi un modèle qui « tourne sur le laptop » n’est pas forcément prêt pour un service en production.

Pourquoi les GPU dominent l’inférence

Les réseaux neuronaux modernes réalisent énormément de calcul matriciel parallèle. Les GPU disposent de nombreux unités d’exécution et d’une bande passante mémoire très élevée, ce qui les rend beaucoup plus adaptés que les CPU généralistes aux grands modèles.

La première contrainte est souvent la VRAM, la mémoire attachée à l’accélérateur. Poids du modèle, KV cache, buffers temporaires et overhead du serveur se la partagent.

Mémoire des poids : première approximation

La quantification, c’est une photographie enregistrée avec moins de profondeur de couleur. Bien plus légère, et la différence ne se voit pas — jusqu’au moment où elle se voit d’un coup.

Un modèle 8B contient environ huit milliards de paramètres appris. À très gros traits, la mémoire des poids est le nombre de paramètres multiplié par leur précision de stockage.

La quantification réduit la précision numérique afin de stocker et parfois calculer plus efficacement. Dire « quatre bits est indiscernable » serait faux de manière universelle. Évaluez exactement le build quantifié que vous comptez déployer.

Le KV cache est la mémoire qui augmente avec l’usage

Le KV cache, ce sont les notes en cours de la conversation. Peu coûteux à compléter, jamais réécrit depuis le début, et la raison pour laquelle le vingtième tour d’un long échange coûte plus cher que le premier.

Pendant une génération autorégressive, le serveur conserve les clés et valeurs d’attention de la séquence pour éviter de recalculer tout le préfixe à chaque token. Ce KV cache croît avec la longueur de contexte, le batch et le nombre de séquences simultanées. Un test mono-utilisateur peut donc sous-estimer énormément la mémoire nécessaire en charge réelle.

Runner local ou serving de production

Ollama et llama.cpp rendent l’expérimentation locale extrêmement simple sur CPU, GPU grand public et Apple Silicon. Ollama sait traiter des requêtes parallèles selon la configuration et la mémoire ; il serait incorrect de le décrire comme intrinsèquement séquentiel.

vLLM, SGLang, TensorRT-LLM et outils similaires visent le débit datacentre. Continuous batching, gestion efficace du KV cache, tensor parallelism et scheduling deviennent déterminants quand plusieurs utilisateurs arrivent en même temps.

Continuous batching

Les requêtes ne finissent pas toutes au même moment. Le continuous batching réutilise immédiatement la capacité libérée par une séquence terminée au lieu d’attendre qu’un batch entier se termine. Cela améliore l’utilisation du GPU et réduit la pénalité d’une réponse exceptionnellement longue.

KV cache paginé

Les serveurs modernes peuvent allouer le cache en blocs plutôt que réserver de grandes zones contiguës par requête. L’idée ressemble à la mémoire virtuelle : allouer où c’est nécessaire et limiter la fragmentation. Les implémentations diffèrent, mais l’effet opérationnel est plus de concurrence utile dans la même VRAM.

Docker joue trois rôles différents

Reproductibilité : figer bibliothèques CUDA, packages et serving entre test et production.

Isolation : exécuter du code généré dans des conteneurs jetables avec filesystem, réseau et credentials contrôlés.

Déploiement : empaqueter des services que l’infrastructure ordinaire sait déployer et mettre à jour.

Kubernetes devient utile si l’échelle et les compétences opérationnelles le justifient. Ce n’est pas un badge de maturité. Docker Compose ou un service de conteneurs managé est souvent une meilleure réponse pour une PME.

Comment challenger un chiffre de débit

Demandez toujours : modèle, quantification, matériel, batch, longueur d’entrée, longueur de sortie, concurrence, time-to-first-token, tokens/s en régime établi et taux d’utilisation supposé. Un benchmark sur prompts courts avec batch plein ne prédit pas une charge faite de contextes de 100 000 tokens et de pics à 9 h.

« Où héberger l’IA ? » mélange souvent quatre couches qui ne résolvent pas le même problème. Séparez interface, gateway, serving modèle et données avant de comparer des produits.

Une gateway devient utile plus tôt qu’on ne le pense

Dès que plusieurs applications ou équipes appellent des modèles, une gateway donne un point unique pour credentials, routage, dépenses, logs, policy et fallback. Refaire cette couche une fois que chaque application possède sa propre clé et son propre code fournisseur est pénible.

Ne confondez pas gateway, interface et fournisseur. LiteLLM peut se placer devant plusieurs fournisseurs. Open WebUI peut se placer devant la gateway. Bedrock ou Foundry peuvent se trouver derrière. Dessinez les couches avant de décider que deux produits sont concurrents.

Les plateformes hyperscaler

AWS Bedrock, Microsoft Foundry et Google Vertex AI offrent catalogues de modèles, identité enterprise, contrôles régionaux et services IA managés dans l’environnement cloud existant. Le critère décisif est souvent l’endroit où vit déjà votre SI, davantage qu’un benchmark isolé.

Vérifié le 20 août 2026 · disponibilité des modèles, régions, quotas et fonctions managées changent fréquemment.

Deux précautions : le prix cloud marketplace peut différer du prix direct du fournisseur, et le modèle le plus récent n’arrive pas forcément partout le même jour. Vérifiez aussi la conformité du service IA précis : la certification générale d’un cloud ne prouve pas que chaque fonctionnalité managée tombe dans le même périmètre contractuel.

Hébergement serverless de poids ouverts

Des acteurs comme Fireworks, Groq, DeepInfra et d’autres exposent des modèles ouverts via des APIs ordinaires facturées à l’usage. C’est un milieu très intéressant : choix et économie des poids ouverts sans exploitation de GPU. Pour beaucoup d’entreprises, c’est la première réponse sensée à « nous voulons utiliser des modèles ouverts ».

GPU loués et serving géré par vous

Vous pouvez louer des accélérateurs puis faire tourner vLLM ou un serveur similaire. Vous contrôlez version du modèle, quantification et comportement du serving sans acheter le matériel. En revanche capacity planning, sécurité, mises à jour et fiabilité restent à votre charge.

Trois architectures de référence

Petite équipe : IA privée rapidement

Interface privée + gateway protégées par SSO/HTTPS, appelant un fournisseur commercial sous conditions business appropriées. Logs et contrôles d’usage sont centralisés. Si le modèle n’a pas besoin d’être local, n’achetez pas un GPU uniquement pour rendre le diagramme « privé ».

Produit client

Application → gateway → un ou plusieurs fournisseurs ; retrieval dans Postgres ou search managé ; queue pour tâches longues ; traces sur chaque requête ; évaluation dans le pipeline de déploiement ; secrets dans le secret manager habituel. Conteneurisez sur la plateforme que l’équipe maîtrise déjà.

Environnement large ou réglementé

Identité enterprise, policy centrale, budgets par équipe, contraintes régionales/souveraines, retrieval sensible aux permissions, observabilité centrale, inventaire IA et supervision humaine documentée par cas d’usage. À cette échelle, identité, procurement et architecture de données prennent souvent plus de temps que l’API modèle.

Ce qui casse en premier à l’échelle

• Quotas et rate limits. La capacité doit être négociée avant le lancement.
• Requêtes longues. Les agents mettent au jour des timeouts conçus pour un web classique.
• Croissance des tokens. Un trafic multi-étapes peut croître plus vite que le nombre d’utilisateurs.
• Retrieval et permissions. Gros index, filtres ACL et fraîcheur d’ingestion peuvent devenir le goulot avant la génération.
• Changement du modèle. Un nom de produit stable peut cacher un comportement différent. Épinglez les versions quand c’est possible et gardez des tests de régression.

Optimiser les tokens ne veut pas dire rendre chaque prompt minuscule. Cela veut dire dépenser du calcul là où il change le résultat métier. La métrique à optimiser est le coût par tâche terminée, pas le tarif le plus bas par million de tokens.

Comptez le contexte caché

La question visible de l’utilisateur peut faire vingt tokens alors que la requête réelle en contient des milliers : system prompt, définitions d’outils, passages retrouvés, historique, mémoire et état agentique. Dans un RAG ou un agent, ce contexte invisible domine souvent la facture.

Les boucles amplifient le phénomène parce que les étapes suivantes transportent ou reconstruisent une partie de l’état précédent. Selon la compression et le cache, la consommation totale peut croître beaucoup plus vite que le nombre visible de messages.

1. Prompt caching

De nombreux fournisseurs peuvent réutiliser le calcul associé à un préfixe identique et facturer les lectures de cache moins cher. Le mécanisme marche surtout si le contenu stable vient d’abord : instructions système, définitions d’outils, exemples réutilisables, puis seulement les enregistrements et données dynamiques.

Les règles et tarifs diffèrent selon le fournisseur. Vérifiez les cache hits dans les métadonnées d’usage au lieu de supposer que votre prompt est « cache-friendly ». Et souvenez-vous : le cache réduit le coût de l’entrée ; il ne rend pas les tokens de sortie gratuits.

Un calcul illustratif

Supposons un prix d’entrée de $3 par million, un cache write à 1,25× et une lecture à 0,10×. Une écriture puis neuf lectures coûtent $3,75 + 9 × $0,30 = $6,45 pour dix utilisations d’un préfixe d’un million de tokens. Le coût effectif devient $0,645 par million, soit 78,5 % de moins que dix entrées normales. Le calcul est réutilisable ; les multiplicateurs ne le sont pas.

2. Routage de modèles

Classification, extraction et transformations simples doivent tourner sur le plus petit modèle qui passe votre évaluation. Les cas difficiles escaladent vers plus fort. L’économie dépend du mix de trafic et du taux d’escalade ; mesurez-la au niveau de la tâche.

3. Batch pour ce qui n’attend personne

Enrichissement nocturne, tagging massif et backfills n’ont pas besoin de latence interactive. Les endpoints batch ou vos propres queues peuvent échanger du temps contre un coût plus faible et une capacité plus régulière.

4. Travaillez le contexte

Retrouvez large puis n’envoyez que les meilleures preuves. Résumez l’historique ancien. Supprimez les champs inutiles des réponses d’outils. N’exposez que les outils pertinents à l’étape. Ces changements réduisent coût, latence et compétition d’attention en même temps.

5. Cache sémantique

Sur un support ou FAQ très répétitif, vous pouvez encoder une nouvelle question et retourner une réponse déjà validée lorsqu’elle est suffisamment proche. Cela supprime l’appel modèle et économise entrée et sortie.

Le risque est de retourner la réponse d’hier à une question subtilement différente ou dépendante du temps. Dérivez le seuil d’exemples annotés, ajoutez des règles de fraîcheur et bypasser le cache pour les informations personnalisées ou très changeantes.

6. Budget de raisonnement

Le raisonnement consomme du compute et souvent des tokens facturables. Allouez-le par tâche. Une analyse de cause racine difficile peut justifier une délibération importante ; extraire un numéro de série ou mettre un mail en forme, rarement.

La métrique finance

Coût par tâche terminée combine prix modèle, retries, outils, échecs et corrections humaines. Un modèle bon marché qui nécessite trois essais peut coûter plus cher qu’un modèle plus cher qui réussit du premier coup. Suivez le coût IA à côté du temps humain économisé, de la valeur créée et du risque évité.

La bonne question de gouvernance n’est pas « ce modèle est-il approuvé ? ». Un même modèle peut être utilisé depuis un compte personnel, un contrat enterprise, une API privée ou une infrastructure contrôlée. Classez le chemin de déploiement et de données, pas seulement la marque.

Classer par lieu de traitement, pas par modèle

Nous avons rédigé une politique IA de groupe pour un groupe coté d’instrumentation scientifique de plus de vingt-cinq sociétés opérationnelles. Le cadre classe les outils selon le lieu de traitement — cloud grand public, IA d’entreprise sous accord, local ou auto-hébergé — et non selon le modèle utilisé. Un même modèle peut relever de niveaux différents selon son déploiement, et c’est exactement ce qui empêche la sortie du trimestre suivant d’invalider la politique.

Une politique simple en trois niveaux

C’est un cadre de politique, pas l’affirmation que tous les produits d’un niveau sont équivalents. Un service enterprise précis peut rester inadapté à cause de la juridiction, des sous-traitants, de la rétention, du contrat ou de la nature même des données.

Deux positions qui ont résisté au conseil

Dans cette même politique de groupe, deux positions ont fait l’essentiel du travail. Une case « ne pas entraîner » a été jugée insuffisante à elle seule, parce que les conditions changent, les fuites arrivent et la justice peut contraindre la divulgation. Et un accord entreprise a été considéré comme ne primant pas sur une obligation contractuelle envers un client sous NDA — l’engagement de l’éditeur est pris envers vous, pas envers votre client.

Désactiver l’entraînement n’est qu’un contrôle parmi d’autres

« Ne pas entraîner sur mes données » répond à une question : ce contenu peut-il servir à améliorer de futurs modèles selon la politique du fournisseur ? Cela ne répond pas automatiquement à l’endroit où les données sont traitées, combien de temps elles restent, qui peut y accéder dans le cadre d’une procédure légale, si votre NDA autorise la divulgation ou si votre organisation peut auditer l’usage.

L’exemple du legal hold, formulé précisément

En 2025, le contentieux engagé notamment par le New York Times a conduit un tribunal américain à imposer à OpenAI la conservation de certaines catégories de contenus consumer et API qui auraient autrement été supprimés. OpenAI indique que cette obligation générale de conservation continue a pris fin le 26 septembre 2025 et que les pratiques ordinaires de suppression ont repris pour les nouvelles données, tandis qu’un ensemble historique limité est resté préservé. Séparément, en décembre 2025, OpenAI a indiqué devoir mettre à disposition dans le contentieux un échantillon désidentifié de 20 millions de conversations consumer sous contrôles stricts.

La leçon n’est pas « chaque chat supprimé est conservé pour toujours » — ce serait faux. La leçon durable est qu’une politique de suppression ordinaire peut être supplantée par une obligation légale valide de conservation ou de communication. Les réglages de confidentialité consumer ne créent pas une immunité face au droit.

Une règle que les collaborateurs retiennent

La formulation est volontairement conservatrice. Elle force une pause avant de partager secret d’affaires, information sous NDA, donnée personnelle, prix confidentiel, résultats non publiés ou information technique soumise à contrôle d’export.

Une bonne politique dit aussi ce qui est encouragé : recherche publique, apprentissage, traduction, idéation, rédaction sur données non confidentielles, code sur jeux approuvés. Une politique qui ne fait que dire « non » pousse souvent les usages hors de la visibilité.

L’IA enterprise amplifie les permissions existantes

Un assistant peut parfaitement respecter les droits SharePoint, Drive ou CRM et quand même révéler un problème qui existait déjà. Un fichier de salaires placé dans un dossier trop largement partagé était techniquement accessible hier ; personne ne savait où le chercher. La recherche sémantique le rend trivial à trouver aujourd’hui.

L’IA n’a pas créé le droit d’accès ; elle a retiré la friction qui cachait l’erreur. Auditez les oversharing avant une recherche enterprise large, appliquez les droits dans le retrieval et envisagez d’exclure RH, juridique, corporate development et autres zones très sensibles de l’indexation générale.

Le shadow AI est un problème d’adoption autant que de politique

Les gens utilisent leurs comptes personnels pour le travail lorsque la voie approuvée n’existe pas, est trop lente ou franchement moins bonne. Commencez par découvrir les usages réels sans transformer l’exercice en chasse disciplinaire. Fournissez un outil approuvé qui résout vraiment le besoin, puis faites respecter la frontière. L’interdiction sans alternative utile pousse l’activité hors des logs.

Six questions avant d’approuver un service

API chinoise hébergée et poids chinois locaux : deux décisions différentes

Une API hébergée transfère vos données d’inférence au fournisseur sous son cadre contractuel et juridictionnel. Des poids téléchargés et exécutés dans votre environnement n’envoient pas les prompts au laboratoire d’origine simplement parce qu’ils ont été créés en Chine. Pour des poids locaux, concentrez-vous plutôt sur licence, provenance, comportement, supply chain et contrôles d’exploitation.

La culture IA est désormais un sujet de conformité en Europe

L’obligation d’AI literacy de l’AI Act s’applique depuis février 2025. Le Digital Omnibus, en vigueur depuis le 27 juillet 2026, l’a réécrite : les organisations doivent désormais prendre des mesures pour soutenir le développement de la culture IA chez les personnes qui utilisent ou opèrent ces systèmes pour leur compte, sans garantir un niveau chez tel ou tel individu. C’est une obligation de moyens, non de résultat : le devoir s’assouplit, il ne disparaît pas. Un programme pragmatique couvre frontières de données, modes de panne connus, habitudes de vérification et preuve de la sensibilisation délivrée.

La gouvernance n’est pas le frein de l’IA. C’est le mécanisme qui permet de lui donner plus de responsabilité sans prétendre qu’elle est devenue déterministe. Une bonne gouvernance élargit ce que l’entreprise peut automatiser en sécurité.

Les risques spécifiques à inscrire au registre

Prompt injection

Les modèles reçoivent instructions et contenus non fiables dans le même grand canal : le contexte. Une instruction malveillante peut donc arriver dans un email, une page web, un document uploadé ou un résultat d’outil, et non uniquement dans le message de l’utilisateur.

Imaginez un email contenant du texte caché demandant à un assistant de transférer des messages sensibles. L’agent lit l’email parce que c’est son travail. S’il possède en plus l’accès à la boîte et un outil d’envoi sans contrainte, l’attaque peut se transformer en action sans malware traditionnel.

La prompt injection reste un risque applicatif majeur. Filtres, délimiteurs et modèles de contrôle réduisent le risque mais ne constituent pas une frontière complète contre un adversaire adaptatif. L’architecture est plus importante.

La « lethal trifecta »

Le motif à plus haut risque combine données privées, contenu non fiable et canal de communication ou d’action vers l’extérieur. Retirer ou contraindre fortement une de ces jambes réduit substantiellement le principal chemin d’exfiltration. Ce n’est pas une preuve que toutes les attaques disparaissent ; c’est un excellent test d’architecture de deux minutes.

Excessive agency

Un système peut recevoir plus d’outils, de permissions ou d’autonomie que la tâche n’en exige. Une petite erreur ou injection devient alors un incident beaucoup plus grand. Appliquez moindre privilège, scopes bornés, validation humaine pour actions irréversibles et budgets d’action explicites.

Autres risques récurrents

• Confabulation : une sortie plausible mais non soutenue entre dans une décision.
• Divulgation d’information sensible : fuite via réponse, logs, index ou processeur externe.
• Data poisoning : contenu manipulé qui entre dans un corpus de retrieval ou d’entraînement.
• Supply chain : modèles, packages, skills, conteneurs ou serveurs MCP introduits sans provenance ni revue.
• Consommation non bornée : boucles, retries ou entrées malveillantes provoquent une dérive de compute et de dépense.
• Permission amplification : l’IA rend une donnée trop largement partagée beaucoup plus facile à trouver.

AI Act européen : situation au 20 août 2026

Les dates ci-dessous ont encore bougé en juillet 2026. Le calendrier du règlement IA détermine lesquelles de ces obligations vous lient, à partir de quelle date, et quelles preuves chacune exige.

Position juridique vérifiée le 20 août 2026 · le périmètre dépend du rôle, du cas d’usage et de la catégorie de risque.

L’article 50 est plus précis que « étiqueter tout contenu IA »

Depuis le 2 août 2026, certains systèmes interactifs doivent être conçus pour informer les personnes lorsqu’elles interagissent directement avec une IA. Les fournisseurs de systèmes générant ou manipulant du contenu synthétique ont, dans le périmètre de l’article 50, des obligations de marquage lisible par machine. Les déployeurs ont des obligations distinctes concernant notamment deepfakes, reconnaissance des émotions ou catégorisation biométrique et certains textes d’intérêt public générés sans revue humaine ou contrôle éditorial.

Pour les violations de l’article 50, les lignes directrices de la Commission indiquent des sanctions pouvant atteindre 15 M€ ou 3 % du chiffre d’affaires mondial annuel. Le plafond de 35 M€ ou 7 % souvent cité pour l’AI Act concerne les catégories les plus graves, notamment les pratiques interdites, pas chaque échec de transparence.

La situation au Royaume-Uni

Le Royaume-Uni ne dispose toujours pas d’un équivalent horizontal unique de l’AI Act. L’usage de l’IA est encadré par les lois existantes et les régulateurs sectoriels : protection des données, égalité, consommation, emploi, sécurité, propriété intellectuelle, etc. En pratique, une entreprise qui opère des deux côtés construit souvent une couche de gouvernance capable de satisfaire obligations UK et exigences européennes pertinentes plutôt que deux systèmes totalement séparés.

Trois cadres à connaître

NIST AI Risk Management Framework. Organise le travail autour de Govern, Map, Measure et Manage. Volontaire, ce n’est pas une certification ; le profil GenAI l’étend aux risques génératifs.

ISO/IEC 42001. Standard de système de management de l’IA certifiable. Il est intéressant en procurement parce qu’une certification indépendante peut fournir la preuve d’un système de management opéré, pas seulement d’une auto-évaluation.

Model AI Governance Framework for Agentic AI de Singapour. Publié en janvier 2026, particulièrement utile pour les agents car il traite explicitement autonomie, contrôles techniques, responsabilité humaine, déploiement progressif et monitoring.

Faire remonter les arbitrages plutôt que les enfouir

Sur cette mission, le livrable le plus important n’était pas la politique. C’était un dossier de décision isolant huit questions qu’un consultant ne devrait pas trancher — fréquence de supervision, répartition de la responsabilité, sanctions, position sur l’IA en RH et recrutement — chacune avec une position proposée, les alternatives et l’arbitrage. En dessous : un registre d’une vingtaine d’outils approuvés et une liste d’interdits où chaque entrée portait une justification écrite, pour qu’elle puisse être défendue et révisée plutôt qu’héritée.

Ce que contient une gouvernance qui fonctionne

• Inventaire. Système, owner, finalité, modèle, classe de données, utilisateurs, route de déploiement, niveau de risque.
• Policy et accès. Services approuvés, classes autorisées, identité, droits.
• Contrôles runtime. Checks d’entrée et de sortie, permissions d’outils, budgets et validations.
• Traces. Prompts ou références, preuves retrouvées, version du modèle, tools, approvals, tokens, coût et résultat, proportionnés au risque.
• Évaluation dans le release path. Rejouer vos tests avant déploiement et après tout changement matériel de modèle, prompt, retrieval ou outil.
• Supervision humaine adaptée au rayon d’impact. Qui vérifie quoi et à quel moment.
• Incident response. Arrêter, contenir, notifier, inverser si possible, préserver les preuves et ajouter le cas au jeu d’évaluation.

Une bonne idée d’IA se transforme souvent en projet data dès que quelqu’un demande où se trouvent réellement les preuves nécessaires. Ce n’est pas un détour ; c’est fréquemment le vrai travail.

Cinq questions avant de lancer le build

1. La donnée existe-t-elle ? Le processus est-il enregistré, ou la connaissance reste-t-elle seulement dans la tête de quelques personnes ?
2. Pouvez-vous y accéder ? Une donnée enfermée dans un logiciel propriétaire, portail fournisseur ou drive personnel est fonctionnellement indisponible.
3. Est-elle assez correcte ? Échantillonnez à la main. L’historique contient souvent des raccourcis tolérables lorsqu’aucune machine ne le réutilisait.
4. Avez-vous les labels ou résultats nécessaires ? Un projet prédictif a besoin de la cible, pas seulement des entrées. « Machine entretenue » n’est pas le même label que « machine tombée en panne ».
5. Avez-vous le droit de l’utiliser ? Contrats, données personnelles, NDA, export control et engagements clients peuvent modifier l’architecture ou arrêter le cas d’usage.

Les modèles génératifs ont changé ce que « data ready » peut vouloir dire

Le machine learning classique exigeait souvent un dataset structuré avant de commencer. Les modèles de langage et multimodaux peuvent extraire de la structure depuis des notes de service, emails, scans, transcripts d’appels et rapports incohérents.

Une bonne première étape pour une organisation peu structurée peut donc être un système qui lit le désordre. La recherche produit une valeur immédiate tandis que l’ingestion commence à créer le dataset plus propre dont auront besoin demain prévision, qualité ou automatisation.

Où se trouvait réellement la connaissance tacite

Sur un conseiller commercial, ce qui rendait le système utile, c’était vingt ans de connaissance interne jamais traitée comme de la donnée : des battle cards sur des présentations périmées circulant dans des groupes de messagerie, des analyses concurrentielles, et le raisonnement derrière les prix plutôt que la grille tarifaire. Collecter et structurer tout cela, c’était le projet. Le modèle était la partie facile.

La connaissance tacite : la donnée que personne n’avait budgétée

Dans une PME d’ingénierie, l’information la plus précieuse explique souvent pourquoi la procédure écrite ne suffit pas : quelle installation exige le support modifié, quel symptôme précède presque toujours la panne, quel détail de plan change le devis. Quelques personnes expérimentées la portent.

Capturez-la délibérément : entretiens structurés, revues de service enregistrées et transcrites, annotations sur cas historiques, champs « pourquoi » dans les workflows. Cette connaissance opérationnelle propriétaire est aussi beaucoup plus défendable qu’un prompt ou un choix de modèle.

Un modèle de maturité en six niveaux

Il s’agit d’un cadre de planification Ascentis, pas d’un standard de l’industrie. Son utilité est de choisir la prochaine étape crédible.

Deux pièges prévisibles

Sauter des niveaux. Une organisation au stade shadow peut techniquement prototyper un agent autonome, mais elle manque souvent d’évaluation, ownership, permissions et incident response pour le maintenir.

Rester bloqué au stade des outils approuvés. Acheter des licences et former les équipes améliore la productivité individuelle sans transformer un process. Passer du niveau 2 au niveau 3 est une décision managériale : redessiner un workflow mesurable autour de la capacité.

Un premier programme IA utile ne commence pas par choisir un framework agentique. Il commence par rendre visibles les usages existants, sélectionner un processus qui mérite l’effort et définir comment mesurer si le résultat est réellement meilleur qu’aujourd’hui.

Jours 1 à 30 : voir la situation réelle

• Demandez quels outils IA sont déjà utilisés et pour quelles tâches. Faites la découverte sans logique punitive afin d’obtenir la vraie image.
• Publiez une policy simple de classes de données et fournissez au moins un outil approuvé que les équipes peuvent réellement utiliser.
• Choisissez un processus à volume suffisant, où le langage ou les documents comptent et où les erreurs sont récupérables.
• Constituez 20 à 50 cas réels avec un résultat acceptable convenu. C’est la première version du jeu d’évaluation.
• Nommez un owner et précisez quelles sorties nécessitent validation humaine.

Ce que soixante jours achètent réellement

Quelques repères tirés de nos propres livraisons. Une preuve de concept de tri du support a pris cinq semaines. Un conseiller commercial privé est passé du MVP à la production en huit. Un digest de veille hebdomadaire auto-hébergé a atteint sa première édition en production en six semaines et demie, contre huit annoncées. Aucun n’était un projet de recherche. Tous étaient étroits, testables et cadrés sur un seul processus.

Jours 31 à 60 : construire la version la moins compliquée

• Essayez d’abord prompt et sortie structurée.
• Si la connaissance interne change, ajoutez retrieval ou outils plutôt que d’entraîner les faits dans le modèle.
• Utilisez du retrieval hybride si les identifiants exacts comptent ; testez un reranker si le jeu de candidats montre un vrai problème de classement.
• Comparez plusieurs niveaux de modèles sur le même jeu et choisissez par réussite de tâche, puis coût et latence.
• Mesurez le taux de correction humaine : c’est l’un des signaux les plus directs de valeur opérationnelle.

Jours 61 à 90 : transformer le prototype en système opérable

• Instrumentez coût par tâche, latence, taux de correction, qualité retrieval, catégories d’échec et abstention.
• Ajoutez identité, permissions, traces, versioning et chemin d’incident.
• Faites le test de la lethal trifecta avant d’autoriser des actions externes.
• Documentez les échecs et ajoutez-les au jeu d’évaluation.
• N’introduisez un agent que si la prochaine étape ne peut raisonnablement pas être prédéterminée. Ajoutez alors état durable, budgets et kill switch.

Où nous avons appliqué cette méthode

Nos cas couvrent veille de marché, gouvernance IA groupe, pipeline support en cinq étapes, automatisation de devis, entrée sur de nouveaux marchés, conseiller commercial mondial et IA embarquée dans un produit. Les noms clients restent confidentiels lorsque convenu ; l’architecture, le changement de process et les résultats mesurés sont décrits pour montrer ce qui a déplacé la valeur au-delà d’une démonstration de chatbot.

Quatre questions à emporter dans chaque réunion IA

1. Quelle couche échoue ? Prompt, contexte, harness ou boucle.
2. Quelles preuves sont réellement dans le contexte ? Si personne ne sait répondre, le système n’est pas assez compris.
3. Comment le succès est-il vérifié ? « Le modèle dit qu’il a terminé » n’est pas un contrôle de production.
4. Quel est le rayon d’impact ? L’autonomie doit suivre la conséquence et la réversibilité, pas le marketing du modèle.

Les termes techniques utilisés dans le guide, avec la définition opérationnelle qui compte lorsqu’on conçoit ou achète un système.

A2A

Protocole Agent-to-Agent, approche d’interopérabilité permettant à des agents de se découvrir et de communiquer.

Agent

Système dans lequel un modèle peut choisir des actions, utiliser des outils, inspecter les résultats puis décider quoi faire ensuite dans une boucle.

Agentic RAG

Retrieval exposé comme outil à l’intérieur d’une boucle agentique, permettant plusieurs recherches et le choix dynamique des sources.

ANN

Approximate Nearest Neighbour : recherche de voisins approximative, échangeant une petite perte de recall mesurable contre une recherche vectorielle beaucoup plus rapide.

Attention

Mécanisme Transformer permettant au modèle de pondérer différemment les relations entre tokens ou représentations à chaque étape de calcul.

Bi-encoder

Architecture de retrieval qui encode question et document séparément afin de pré-indexer les documents.

Blast radius

Pire conséquence crédible d’une action automatisée erronée, combinée à sa détectabilité et sa réversibilité.

Chunk

Unité récupérable découpée dans une source plus grande. Sa frontière définit la plus petite unité de preuve que le RAG peut retourner.

Computer use agent

Agent qui interprète une interface graphique et agit via souris, clavier ou contrôles UI. Une API reste préférable lorsqu’elle existe.

Context engineering

Conception des instructions, preuves, mémoire, outils et état disponibles pour chaque inférence.

Context window

Capacité maximale en tokens disponible au modèle pour l’inférence courante.

Continuous batching

Technique de serving qui regroupe des requêtes tout en remplaçant les séquences terminées par du nouveau travail pour garder le GPU occupé.

Corrective RAG

Motif de retrieval qui évalue la qualité des preuves avant génération et déclenche une action corrective si elles sont insuffisantes.

Cosine similarity

Cosinus de l’angle entre deux vecteurs. Sa distribution pratique dépend du modèle d’embedding et du corpus.

Cross-encoder

Modèle de reranking qui lit question et candidat ensemble pour juger leur pertinence plus précisément.

Data residency

Lieu physique ou contractuel où les données sont traitées et stockées.

Data sovereignty

Degré de contrôle permettant à une organisation d’opérer et gouverner une capacité data/IA critique sous des règles qu’elle maîtrise.

Deletion propagation

Suppression de l’information source dans toutes ses représentations dérivées : chunks, vecteurs, indexes, graphes et caches, avec traitement distinct des sauvegardes et obligations de conservation.

Distillation

Entraînement d’un modèle plus petit pour reproduire un comportement utile d’un modèle enseignant ou d’un dataset produit par lui.

Document AI

Technologies d’extraction de sens structuré depuis des documents : OCR, analyse de layout et modèles vision-language.

Embedding

Représentation numérique utilisée pour comparer une similarité sémantique ou apprise entre entrées.

Few-shot prompting

Ajout de quelques exemples représentatifs entrée/sortie dans le contexte pour montrer le comportement attendu.

Fine-tuning

Entraînement supplémentaire modifiant le comportement du modèle à partir d’exemples de tâche ou de domaine. Mieux adapté au comportement qu’à la connaissance factuelle changeante.

Gradient boosting

Famille de méthodes de ML supervisé très performante sur de nombreux problèmes prédictifs tabulaires.

Groundedness

Degré auquel les affirmations d’une réponse sont effectivement soutenues par les preuves fournies au modèle.

Guardrail

Contrôle automatique ou policy autour des entrées, sorties ou actions. Chaque guardrail individuel doit être considéré comme faillible.

Hallucination

Sortie fluide présentant comme fiable un contenu faux ou non soutenu.

Harness

Runtime autour du modèle : outils, permissions, sandbox, credentials, validation, budgets et journalisation.

Hit@k

Indique si au moins un élément pertinent de référence apparaît dans les k premiers résultats.

HNSW

Hierarchical Navigable Small World, index de voisins approximatifs basé sur un graphe à plusieurs niveaux.

Hybrid retrieval

Combinaison de recherche vectorielle sémantique et de recherche lexicale ou exacte, puis fusion des classements.

Inference

Exécution d’un modèle entraîné pour produire prédictions, texte, tool calls ou autres sorties.

JSON mode

Mode de génération garantissant une syntaxe JSON valide, mais pas forcément le bon schéma ni des valeurs correctes.

Jurisdiction

Régimes juridiques et pouvoirs d’accès gouvernementaux pouvant s’appliquer à un fournisseur ou traitement.

Knowledge graph

Entités et relations stockées explicitement de façon à pouvoir être traversées et interrogées.

KV cache

Mémoire d’inférence stockant clés et valeurs d’attention pour les séquences actives afin de ne pas recalculer tout le préfixe à chaque token.

Lethal trifecta

Combinaison risquée de données privées, contenu non fiable et canal d’action ou de communication externe.

LiteLLM

Gateway IA pouvant présenter une API commune devant plusieurs fournisseurs et déploiements de modèles.

Localisation

Règle imposant que les données ou traitements restent dans un territoire ou environnement défini.

Matryoshka embeddings

Embeddings entraînés pour que des préfixes plus courts du vecteur conservent de l’information utile, ce qui permet de tester une réduction de dimensions.

MCP

Model Context Protocol, interface commune pour exposer outils et ressources à des clients IA compatibles.

Mixture of Experts (MoE)

Architecture qui route chaque token vers un sous-ensemble de composants spécialisés plutôt que d’activer tout le réseau à chaque fois.

Model supply chain

Chaîne complète de dépendances d’un runtime IA : poids, tokenizer, configuration, conteneurs, serveur d’inférence, drivers, packages, modèles secondaires, outils, registries, télémétrie et updates.

MRR

Mean Reciprocal Rank : moyenne de 1 divisé par la position du premier résultat pertinent.

MTEB

Massive Text Embedding Benchmark, suite de tests et leaderboard couvrant plusieurs tâches d’embedding.

Multimodal

Capacité à traiter plusieurs modalités, par exemple texte + image, audio ou vidéo.

nDCG@k

Métrique de classement favorisant les résultats très pertinents en haut tout en gérant des niveaux de pertinence gradués.

Ontology

Modèle formel de types d’entités, relations, contraintes et significations.

Open weight

Modèle dont les paramètres entraînés sont téléchargeables sous licence. Ce n’est pas automatiquement synonyme d’open source.

Orchestration

Plomberie coordonnant modèles, outils, état, retries, routage, traces, budgets et caches.

Parameters

Poids numériques appris dans un modèle. Leur nombre influence mémoire et calcul sans déterminer à lui seul la capacité.

Permission amplification

Effet par lequel l’IA rend une information déjà trop largement partagée beaucoup plus facile à découvrir et combiner.

pgvector

Extension PostgreSQL ajoutant types vectoriels et indexes de similarité à une base relationnelle existante.

Precision@k

Part des k premiers résultats retrouvés qui sont effectivement pertinents.

Prompt caching

Réutilisation du calcul d’un préfixe de prompt répété afin de rendre l’entrée suivante moins chère et souvent plus rapide.

Prompt injection

Instructions cachées dans du contenu non fiable tentant d’influencer un modèle ou agent en dehors de la tâche voulue par l’utilisateur.

Quantisation

Représentation des poids ou vecteurs à plus faible précision numérique pour réduire la mémoire et parfois accélérer le calcul.

RAG

Retrieval-augmented generation : fournir à un modèle génératif des preuves externes pertinentes au moment de la requête.

Recall@k

Part de tous les éléments pertinents retrouvée dans les k premiers résultats.

Realtime voice agent

Système vocal qui écoute, raisonne, utilise des outils et répond avec faible latence tout en gérant prise de tour et interruption ; il peut être en cascade ou speech-to-speech natif.

Reranker

Modèle de second étage qui rescrore les candidats du retrieval par rapport à la question avant leur passage à la génération.

RRF

Reciprocal Rank Fusion : fusion de classements par position plutôt que par addition de scores bruts incompatibles.

Sandbox

Environnement d’exécution isolé avec filesystem, credentials et réseau restreints.

Schema-constrained output

Génération contrainte pendant le décodage afin que la structure de sortie respecte un schéma déclaré.

Self-RAG

Approche de recherche précise entraînant dans le modèle des comportements de retrieval et d’auto-réflexion.

Semantic caching

Réutilisation d’une réponse validée lorsqu’une nouvelle requête est suffisamment proche et que les règles de fraîcheur l’autorisent.

Shadow AI

Usage professionnel de services ou comptes IA non approuvés, hors logs, contrats et contrôles de l’organisation.

Similarity threshold

Seuil minimal de pertinence ou distance maximale utilisé pour rejeter les résultats faibles ; il doit venir de données annotées.

System prompt

Instructions permanentes fournies par l’application pour cadrer le comportement du modèle.

Tacit knowledge

Expérience et jugement détenus par les personnes mais pas encore capturés dans un enregistrement organisationnel réutilisable.

Taxonomy

Hiérarchie de catégories ou concepts, plus simple qu’une ontologie complète.

Temperature

Paramètre d’échantillonnage modifiant la concentration de la distribution de probabilité du prochain token.

Token

Unité de base traitée par un modèle : mot, fragment de mot, ponctuation ou autre élément encodé.

Top-p

Échantillonnage nucleus limitant la génération au plus petit ensemble de candidats dont la probabilité cumulée atteint p.

Vector database

Base ou moteur de recherche capable de stocker des vecteurs, construire des indexes de similarité et appliquer des filtres.

Vision-language model

Modèle multimodal capable d’interpréter images ou pages de documents conjointement à des instructions en langage.

vLLM

Serveur d’inférence haut débit pour modèles de langage, conçu autour d’un scheduling et d’une gestion du KV cache efficaces.

VRAM

Mémoire de l’accélérateur utilisée par poids, KV cache et état de travail de l’inférence.

Wrapper

Application dont la génération IA est fournie par un modèle externe ; son caractère « mince » dépend de la valeur créée par les données, le workflow et l’intégration autour de l’appel.

Zero Data Retention

Disposition fournisseur selon laquelle les entrées et sorties API éligibles ne sont pas conservées au-delà du traitement nécessaire, sous réserve des conditions exactes du service.