Choix de stack technique

Pourquoi ce chapitre est le plus utile

La majorité des produits IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire qui échouent ne meurent pas d'un mauvais modèle : ils meurent d'un choix d'architecture pris trop tôt, sur des critères marketing plutôt que techniques, et jamais reconsidéré. Une équipe qui part sur du self-host parce que « c'est plus sérieux » se retrouve à maintenir une infrastructure GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire pour un produit qui aurait tenu sur une API à 200 € par mois. Une équipe qui empile un RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire dès le POC parce que « c'est la bonne pratique » complexifie un problème qui n'en avait pas besoin. Une équipe qui scale sans évaluation découvre les régressions via les tickets support.

Ce chapitre ne donne pas une réponse unique : il donne une grille d'arbitrage. Trois décisions structurent l'essentiel des projets — API ou self-host, RAG ou non, et comment évaluer ce qui est livré. Chacune doit être revue à chaque changement d'échelle, de réglementation ou de contrat client, pas figée au lancement.

API managée ou self-host : le vrai arbitrage

La question n'est presque jamais « lequel est le meilleur » mais « lequel correspond à mes contraintes actuelles ». Quatre critères pèsent plus que la performance brute du modèle.

Coût total de possession. Une API facture à l'usage : pas d'investissement initial, coût proportionnel au trafic. Le self-host inverse la structure — coût fixe élevé (GPU, orchestration, MLOps) puis coût marginal faible par requête. Le point de bascule se situe généralement entre 5 et 20 millions de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire traités par mois selon le modèle visé, mais ce chiffre bouge vite avec les baisses de prix des fournisseurs d'API.

Sensibilité des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire. Un secteur réglementé (santé, finance, secteur public) impose souvent un traitement en environnement maîtrisé. Certains fournisseurs d'API proposent des garanties contractuelles solides (zero data retention, hébergement régional), ce qui répond à une partie du problème sans self-host complet. Il faut lire le DPA (Data Processing Agreement) ligne par ligne avant de conclure qu'une API est ou n'est pas compatible avec une contrainte réglementaire.

Contrôle et dépendance. Une API managée expose l'équipe aux décisions du fournisseur : dépréciation de modèle, changement de tarif, limitation de débit en période de forte demande. Le self-host donne un contrôle total sur les poids et le comportement, au prix d'une dette de maintenance permanente (mises à jour de sécurité, montée de version des runtimes d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire, supervision GPU).

Vitesse de mise sur le marché. Une API se met en œuvre en quelques heures. Un déploiement self-host correct — avec autoscaling, observabilité, gestion des pannes — prend plusieurs semaines même avec une équipe expérimentée.

Le prix d'une carte A100 ou H100 loué à l'heure n'est qu'une fraction du coût réel. Il faut ajouter : l'ingénieur MLOps qui maintient le serveur d'inférence, la supervision de la dérivedériveIADégradation progressive des performances d'un modèle après son déploiement, causée par l'évolution des comportements ou du contexte. Elle impose surveillance et réentraînement.Voir dans le glossaire de performance, la gestion des pics de charge sans sur-provisionner en permanence, et le temps perdu chaque fois qu'un nouveau modèle open-weights sort et qu'il faut réévaluer s'il vaut la peine de migrer. Une équipe qui sous-estime ces coûts se retrouve avec un TCO supérieur à celui d'une API, pour un contrôle qu'elle n'exploite pas vraiment.

Une startup B2B lance un assistant de rédaction de comptes rendus et choisit le self-host dès le POC, convaincue que cela deviendra nécessaire au scale. Six mois plus tard, elle traite 800 000 tokens par jour — largement sous le seuil de rentabilité du self-host — mais consacre 30 % du temps d'un ingénieur senior à maintenir l'infrastructure d'inférence. Basculer sur une API managée avec cache de promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire aurait libéré ce temps pour le produit. Le choix initial n'était pas absurde en théorie, il était prématuré par rapport au volume réel.

La bonne pratique consiste à démarrer sur API managée sauf contrainte réglementaire bloquante dès le premier jour, puis à instrumenter le coût par requête et le volume mensuel pour objectiver le moment du basculement, plutôt que de le décider par intuition.

RAG : un outil de précision, pas un réflexe

Le Retrieval-Augmented Generation consiste à injecter dans le prompt des extraits de documents pertinents, récupérés dynamiquement, avant de générer une réponse. L'objectif est de fonder la réponse sur des sources vérifiables plutôt que sur la seule mémoire paramétrique du modèle.

Le pipeline standard suit cinq étapes : découpageChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire des documents en fragments (chunking), transformation de chaque fragment en vecteur (embeddingembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire), indexation dans une base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire, récupération des fragments les plus proches de la requête au moment de l'inférence, puis assemblage du prompt final avec ces fragments comme contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire.

Chacune de ces étapes est un point de défaillance possible, ce qui explique pourquoi un RAG mal construit produit des réponses pires qu'un simple prompt sans contexte :

• Chunking trop grossier — des fragments de plusieurs pages diluent l'information pertinente et gonflent inutilement le prompt.
• Chunking trop fin — des fragments de deux phrases perdent le contexte nécessaire à leur interprétation.
• Mauvais modèle d'embedding — un modèle d'embedding généraliste capture mal le vocabulaire d'un domaine très spécialisé (juridique, médical, technique).
• Recherche par similarité sémantique seule — elle rate parfois des correspondances exactes (référence, numéro de contrat, nom propre) qu'une recherche lexicale classique aurait trouvées immédiatement. D'où l'intérêt d'une recherche hybride (vectorielle + mots-clés).
• Absence de reranking — les k premiers résultats d'une recherche vectorielle ne sont pas toujours les plus pertinents ; une étape de reclassement par un modèle dédié améliore souvent la précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire de façon mesurable.

Fournir un contexte pertinent au modèle augmente la probabilité qu'il s'appuie dessus, mais rien ne l'empêche structurellement d'ignorer ce contexte ou de le mal interpréter, surtout si les fragments récupérés sont contradictoires ou insuffisants. Un RAG sans étape de vérification (citation de la source, score de confiance, ou contrôle humain sur les cas à fort enjeu) donne une fausse impression de fiabilité. Traiter le RAG comme une solution complète au problème de la véracité est l'erreur de conception la plus fréquente sur ce sujet.

Quand un RAG est justifié : le produit doit répondre à partir d'un corpus propriétaire ou qui évolue plus vite que les cycles de mise à jour d'un modèle, le volume de documents dépasse ce qu'un prompt peut raisonnablement contenir, ou la traçabilité des sources est une exigence produit (citer le document d'origine).

Quand un RAG ne l'est pas : le corpus tient dans la fenêtre de contexte du modèle (les fenêtres de plusieurs centaines de milliers de tokens rendent cette option de plus en plus viable), le besoin est ponctuel plutôt que répété, ou l'équipe n'a pas encore la capacité de maintenir un pipeline d'indexation à jour. Dans ces cas, un prompt bien structuré avec le contenu directement inséré (ce qu'on appelle parfois le « long-context stuffing ») est plus simple, plus rapide à livrer, et souvent tout aussi performant en dessous d'un certain volume.

Construire un prototype avec injection directe du contenu dans le prompt permet de valider l'utilité produit avant d'investir dans une infrastructure de récupération. Si les tests montrent que le contexte nécessaire dépasse la fenêtre disponible ou que la latence de traitement devient problématique, alors le RAG devient une réponse à un problème identifié plutôt qu'une architecture par précaution.

Évaluation : la brique la plus souvent négligée

Un produit IA sans évaluation systématique fonctionne sur la seule impression subjective de l'équipe qui l'a construite. Cette impression se dégrade sans que personne ne le remarque : un changement de prompt, une mise à jour de modèle côté fournisseur, ou un nouveau cas d'usage peuvent faire chuter la qualité sans qu'aucune alerte ne se déclenche. L'évaluation sert précisément à rendre cette dégradation visible avant qu'elle n'atteigne les utilisateurs.

Deux familles complémentaires structurent une stratégie d'évaluation solide.

L'évaluation offline s'appuie sur un jeu de données de référence (golden dataset) : un ensemble de cas représentatifs avec, pour chacun, une réponse attendue ou des critères de qualité explicites. Ce jeu sert de test de non-régression, exécuté à chaque changement de prompt, de modèle ou de paramètre de récupération. Les métriques varient selon la tâche : exactitude factuelle, respect d'un format, taux de citation correcte des sources pour un RAG, ou score attribué par un juge automatisé.

Le LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire — utiliser un modèle pour noter la sortie d'un autre modèle selon une grille de critères — permet de faire passer l'évaluation à l'échelle sans recruter une équipe d'annotateurs humains pour chaque itération. Cette méthode a ses limites : le juge hérite des biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire et angles morts des modèles de langage en général, et sa cohérence doit être calibrée en la comparant régulièrement à des évaluations humaines sur un échantillon.

L'évaluation online mesure le comportement en production : taux de reformulation d'une requête (signe que la première réponse n'a pas satisfait), taux d'abandon, feedback explicite (pouce levé ou baissé), et pour les produits transactionnels, taux de conversion ou de résolution effective. Elle capture des signaux que l'évaluation offline ne peut pas anticiper, notamment la diversité réelle des requêtes utilisateurs, souvent bien plus large que ce qu'un golden dataset construit en amont a couvert.

Les jeux de test conçus uniquement par l'équipe produit ont tendance à couvrir les cas qu'elle a en tête, pas ceux que les utilisateurs soumettent réellement. Dès que le produit reçoit du trafic réel, il faut échantillonner des requêtes effectives — en particulier celles qui ont généré une reformulation ou un signal négatif — pour enrichir le jeu de testjeu de testIAPartie des données réservée à l'évaluation finale, à n'utiliser qu'une seule fois. Ajuster le modèle d'après ses résultats sur ce jeu lui ôte toute valeur de mesure indépendante.Voir dans le glossaire en continu.

Une checklist minimale avant tout passage à l'échelle :

1. Un golden dataset d'au moins 50 à 100 cas couvrant les scénarios critiques et les cas limites connus.
2. Un pipeline d'évaluation automatisé exécuté à chaque changement de prompt ou de modèle, avec seuil de blocage en cas de régression.
3. Un mécanisme de feedback utilisateur en production, même minimal (pouce haut/bas suffit pour démarrer).
4. Une revue humaine périodique d'un échantillon de sorties réelles, pas seulement des métriques agrégées.
5. Une procédure de rollback rapide si une évaluation online détecte une dégradation après un déploiement.

Architecture hybride : ne pas figer un choix binaire

Dans la pratique, les produits matures combinent souvent plusieurs approches plutôt que de trancher une fois pour toutes. Une API managée peut gérer le trafic courant pendant qu'un modèle self-host traite les cas les plus sensibles ou les plus volumineux. Un RAG peut coexister avec de l'injection directe de contexte selon la taille du corpus concerné par chaque requête. Cette flexibilité a un coût d'ingénierie — orchestrer un routage entre plusieurs backends, maintenir deux chaînes d'évaluation — qui ne se justifie que lorsque le volume ou la diversité des cas d'usage le rend nécessaire.

Le point commun à ces trois décisions — API/self-host, RAG ou non, niveau d'évaluation — est qu'elles doivent rester réversibles. Documenter les critères qui ont motivé un choix, et les seuils qui déclencheraient sa remise en cause, évite de porter indéfiniment une architecture pensée pour un contexte qui n'existe plus.

Ce qu'il faut retenir avant le chapitre suivant

Le choix de stack n'est pas une question de préférence technique mais d'alignement entre contraintes (données, volume, budget, délai) et architecture. Démarrer simple, instrumenter l'évaluation dès le premier déploiement, et ne complexifier — RAG, self-host, architecture hybride — qu'en réponse à un besoin mesuré, pas anticipé, reste la trajectoire la plus robuste observée sur des projets réels.