Intégrer une IA générative en production, du POC à la fonctionnalité qui tient

Il y a le moment où la démo passe, et le moment où la fonctionnalité tient. Entre les deux, il y a un projet entier. Intégrer une IA générative en production, ce n’est pas prolonger un prototype de quelques jours, c’est construire tout ce que le prototype avait le droit d’ignorer : l’ancrage sur vos données, les garde-fous, la mesure de la qualité, les logs, et le comportement du système quand le modèle répond mal ou ne répond pas.

Chez Squirrel, nous développons des applications sur mesure depuis 2014 et nous mettons des briques d’IA entre les mains d’utilisateurs réels. Le scénario que nous voyons le plus souvent : un POC réussi qui donne confiance, puis une fonctionnalité que plus personne n’utilise six mois plus tard parce qu’elle s’est trompée trois fois de suite sur des cas que personne n’avait testés. Cet article décrit ce qu’il faut poser pour éviter ça.

Intégrer une IA générative en production : pourquoi le POC ne suffit pas

Ce qu’un POC prouve réellement

Un POC ou prototype répond à une seule question : est-ce que la technologie sait faire, dans un cas favorable, ce qu’on espère qu’elle fasse ? La réponse est souvent oui. En quelques jours, avec un modèle du marché et une dizaine de documents, on obtient un assistant qui répond juste ou un classement de dossiers qui semble pertinent.

Le piège est que ce oui se lit comme une promesse de production. Or le POC est joué sur un terrain choisi : des données propres, des questions posées par ceux qui ont conçu le système, aucune contrainte de temps de réponse, aucun budget d’appels, aucune obligation de justifier une réponse. Enlevez ces conditions favorables, et le même système devient imprévisible.

Six points de rupture entre la démo et le vrai usage

Les projets que nous reprenons échouent presque toujours sur les mêmes points. Ils ne sont pas exotiques, ils sont juste invisibles tant que l’on reste en démo.

• Les cas limites. Une question hors périmètre, mal orthographiée ou ambiguë, et le modèle invente une réponse plausible avec aplomb.
• La latence. Ce qui passait en démo devient insupportable dans un parcours où l’utilisateur attend devant son écran, surtout sur mobile en réseau dégradé.
• Les coûts. Facturés au volume de jetons, ils sont dérisoires à dix requêtes par jour et beaucoup moins à dix mille.
• L’absence d’évaluation. Sans jeu de cas de référence, personne ne sait dire si la version d’aujourd’hui est meilleure que celle de la semaine dernière.
• La dépendance au fournisseur. Une version dépréciée, un tarif qui change, une limite d’usage, et le comportement de votre produit bouge sans que vous n’ayez rien touché.
• La traçabilité. Un utilisateur conteste une réponse, et vous n’avez ni la question exacte, ni les sources utilisées, ni la version du modèle.

Aucun de ces points ne se règle par un meilleur prompt. Ils se règlent par une architecture, et cette architecture est un projet de développement classique, avec ses arbitrages et son budget.

Ancrer le modèle sur vos données : l’architecture RAG en production

Récupérer d’abord, générer ensuite

Le RAG (Retrieval Augmented Generation) consiste à chercher, au moment de la question, les extraits pertinents dans vos propres contenus, puis à ne demander au modèle que de rédiger une réponse à partir d’eux. Le modèle cesse d’être une source de connaissance, il devient un moteur de reformulation. C’est le levier le plus efficace contre les réponses inventées, parce qu’il déplace le problème vers un terrain que vous maîtrisez. Un RAG qui répond mal a d’ailleurs presque toujours un problème de récupération, pas de génération : si le bon paragraphe n’est jamais remonté, aucun modèle ne le devinera.

Ce qui fait vraiment la qualité d’une architecture RAG

Le schéma de principe tient en trois lignes, la mise en œuvre beaucoup moins. Ces points font la différence entre un RAG de démo et un RAG exploitable :

• Le découpage des documents, qui doit respecter la structure logique du contenu et pas une longueur arbitraire.
• La fraîcheur de l’index, avec une réindexation automatique quand un document change, sinon l’assistant répond juste selon une procédure abrogée.
• Les droits d’accès, propagés jusqu’à la recherche, pour qu’un utilisateur ne voie jamais un extrait auquel il n’a pas droit.
• La recherche elle-même, où combiner recherche vectorielle et recherche par mots-clés donne en général de bien meilleurs résultats que le vectoriel seul.
• La citation des sources dans la réponse, qui permet à l’utilisateur de vérifier et à vous de tracer.

Tout cela vit sur vos systèmes existants : votre base, vos fichiers, votre CRM, votre outil métier. C’est un travail de back-office et d’API avant d’être un travail d’IA, et c’est généralement là que passe la majorité du temps de développement.

Garde-fous : contraindre les entrées, valider les sorties

Un modèle de langage produit du texte, pas une garantie. En production, il faut encadrer ce qui entre et vérifier ce qui sort, sans supposer que le modèle se comportera bien.

Côté sortie, notre règle est simple : rien de ce que produit le modèle n’est utilisé tel quel par un autre système sans validation. Si la réponse doit être structurée, on impose un format et on rejette ce qui ne s’y conforme pas. Si elle déclenche une action (créer une commande, envoyer un message), cette action passe par vos règles métier habituelles, avec les mêmes contrôles que si un humain l’avait demandée. Et quand le RAG ne trouve rien de pertinent, le système doit avoir le droit de dire qu’il ne sait pas. Une réponse absente vaut mieux qu’une réponse fausse.

Côté entrée, l’injection de prompt reste le risque numéro un identifié par l’OWASP Top 10 pour les applications LLM, aux côtés de la fuite d’informations sensibles et de l’agentivité excessive. Rien de théorique dès lors que votre IA lit des contenus fournis par des tiers ou agit sur vos systèmes. Le principe de moindre privilège s’applique à une IA comme à n’importe quel composant : elle n’accède qu’à ce dont elle a besoin et ne déclenche que ce qu’on l’a explicitement autorisée à déclencher.

Un jeu d’évaluation avec de vrais cas, sinon rien

C’est la brique la plus souvent absente, et c’est celle qui coûte le plus cher à ne pas avoir. Sans jeu d’évaluation, toute modification du prompt, du modèle ou du découpage documentaire devient un pari. On corrige un cas signalé par un utilisateur, on en casse trois autres, et personne ne s’en aperçoit avant la prochaine réclamation.

Le jeu d’évaluation n’est pas un outil compliqué, c’est une discipline. Nous constituons avec le client une liste de cas issus du terrain : les questions réellement posées, les dossiers réellement traités, y compris les moches, les ambigus et ceux qui n’ont pas de bonne réponse. Chaque cas porte le résultat attendu ou, à défaut, les critères qui rendent une réponse acceptable. Cette liste devient la suite de tests de la fonctionnalité, rejouée à chaque changement, exactement comme des tests automatisés sur du code classique.

Quelques métriques suffisent au départ : la bonne source a-t-elle été retrouvée, la réponse s’appuie-t-elle dessus, le format attendu est-il respecté, le système a-t-il bien refusé de répondre quand il le fallait. On peut faire noter une partie de ces critères par un second modèle, à condition d’avoir vérifié à la main que son jugement colle au vôtre. Le Generative AI Profile du NIST (AI 600-1) place d’ailleurs cette capacité à mesurer avant de déployer au cœur de sa démarche.

Observabilité, traçabilité et maîtrise des coûts

Tracer chaque réponse de bout en bout

Quand un utilisateur conteste une réponse, vous devez pouvoir reconstituer ce qui s’est passé. Cela suppose de journaliser, pour chaque appel : la question, les extraits récupérés, le prompt envoyé, la réponse produite, le modèle et sa version, la durée et le volume de jetons. Sans ces éléments, l’analyse d’incident se résume à des suppositions.

Ces traces posent une question de données personnelles : elles doivent être minimisées, avec une durée de conservation définie et un accès restreint, comme n’importe quel log sensible. Bonne nouvelle, les conventions sémantiques OpenTelemetry couvrent désormais les appels de modèles : cette observabilité se branche sur vos outils de supervision existants plutôt que d’imposer un outillage parallèle.

Traiter le coût comme une métrique produit

Le coût d’un appel dépend surtout de la taille du contexte envoyé. Un RAG mal réglé qui empile vingt extraits pour n’en utiliser qu’un multiplie la facture sans améliorer la réponse. Les leviers sont connus : réduire le contexte au nécessaire, mettre en cache les questions récurrentes, réserver le modèle le plus puissant aux cas qui le méritent, poser des quotas. Suivre le coût par requête dès le premier jour évite la mauvaise surprise du troisième mois.

Plan de repli et indépendance vis-à-vis du fournisseur

Un fournisseur de modèle peut être indisponible, ralentir, déprécier une version ou modifier ses tarifs. Ce sont des événements normaux, pas des accidents, et votre application doit savoir quoi faire quand ils surviennent. Le minimum : isoler l’appel au modèle derrière une couche interne, ne jamais coder en dur un nom de modèle à vingt endroits, et définir un repli explicite (basculer vers un autre fournisseur, servir une réponse en cache, ou afficher un message honnête et proposer le parcours classique sans IA).

Une fonctionnalité assistée par IA doit pouvoir se dégrader proprement, c’est-à-dire redevenir utilisable sans l’IA. Si le parcours entier s’écroule quand le modèle tombe, ce n’est plus une assistance, c’est une dépendance critique, à traiter avec le niveau d’exigence correspondant. Nous posons cet arbitrage dès le cadrage, avec la même méthode de travail que sur n’importe quelle brique sensible. Et changer de modèle sans tout reconstruire suppose d’avoir gardé son jeu d’évaluation : c’est lui qui vous dira en quelques heures si le remplaçant tient la route sur vos cas.

La boucle de retour utilisateur, ce qui fait progresser le produit

Une IA en production s’améliore par ce que ses utilisateurs en font. Prévoir un moyen simple de signaler une réponse inutile ou fausse, directement dans l’interface, coûte peu et rapporte beaucoup : ces signalements alimentent le jeu d’évaluation, orientent les corrections et révèlent les usages auxquels personne n’avait pensé.

Encore faut-il que quelqu’un les lise. Une boucle de retour sans rituel de traitement est un formulaire mort : fixez dès la mise en ligne qui relit les signalements, à quelle fréquence, et ce qui déclenche une correction. Si vous en êtes plutôt à choisir un prestataire, notre article wrapper ChatGPT ou vraie solution IA traite la même question côté acheteur.

Questions fréquentes sur la mise en production d’une IA générative

Combien de temps faut-il pour intégrer une IA générative en production ?

Le POC se fait en quelques jours. La mise en production se compte en semaines ou en mois, selon le nombre de sources à connecter, le niveau de fiabilité attendu et les contraintes de conformité. La variable dominante n’est presque jamais le modèle, c’est l’accès propre à vos données et la validation métier de ce que le système a le droit de faire.

Peut-on garder un POC comme base de la version de production ?

Partiellement. Les prompts, les enseignements et les cas identifiés se réutilisent, et c’est précieux. Le code, en revanche, a été écrit pour démontrer, pas pour tenir : ni gestion d’erreur, ni traçabilité, ni tests. Le conserver par économie coûte en général plus cher que de le réécrire.

Faut-il un modèle hébergé en interne ?

Pas nécessairement. Les modèles hébergés par un fournisseur conviennent à la majorité des projets, avec un contrat qui encadre l’usage des données. L’hébergement interne se justifie quand la sensibilité des données, une contrainte réglementaire ou un volume très élevé le rendent pertinent. C’est une décision de cadrage, pas un dogme, et nous en discutons projet par projet dans le cadre de nos expertises.