Comment intégrer l'IA dans votre produit

Chaque roadmap produit contient désormais « ajouter de l'IA », et la plupart de ces fonctionnalités seront discrètement supprimées dans l'année. Non pas parce que la technologie ne fonctionne pas — elle fonctionne remarquablement bien — mais parce qu'elle a été greffée pour paraître moderne plutôt que pour résoudre un vrai problème. Les équipes qui réussissent avec l'IA ne sont pas celles qui disposent des modèles les plus sophistiqués ; ce sont celles qui ont choisi la bonne tâche à confier à un modèle et qui ont conçu leur architecture en tenant compte de ses faiblesses. Bien intégrer l'IA relève moins du choix du modèle que du jugement produit. Voici notre approche.

Partir d'un besoin, pas d'un modèle

Le schéma d'échec est toujours le même : une équipe décide d'« utiliser un LLM » puis cherche où le placer. C'est construire une solution en quête d'un problème, et cela produit invariablement des fonctionnalités que personne ne conserve. Inversez le raisonnement. Cherchez là où vos utilisateurs perdent du temps, se bloquent, abandonnent un parcours ou fixent un champ vide, puis demandez-vous si un modèle de langage apporte genuinement une aide à cet endroit précis.

Les bons candidats partagent un profil reconnaissable :

• Entrée non structurée : texte libre, documents, données désordonnées qu'une règle ne sait pas analyser.
• Tolérance à l'approximation : une réponse suffisamment bonne est genuinement utile, et l'utilisateur peut détecter les erreurs.
• Tâche fastidieuse pour un humain : un travail réel que les gens font actuellement à la main et qu'ils n'apprécient pas.

Résumer de longues conversations, rédiger une première version, extraire des champs depuis un texte désordonné, répondre à des questions sur votre propre documentation — ces cas correspondent au profil. Les mauvais candidats exigent des réponses exactes, des garanties absolues, ou disposent déjà d'une solution déterministe parfaitement efficace.

Là où les LLM se justifient

• Rédaction et reformulation. Générer un point de départ qu'un humain retravaille ensuite est une utilisation naturelle — le critère est « mieux qu'une page blanche », pas « parfait ». Brouillons de réponses, premier jet de contenu, résumés.
• Extraction et classification. Transformer du texte libre en données structurées exploitables par votre application : extraire des champs d'une facture, étiqueter des tickets, router des messages.
• Questions-réponses sur vos données. Récupération ancrée dans votre propre contenu, pour que les utilisateurs obtiennent des réponses depuis votre base de connaissances plutôt que d'avoir à la parcourir.
• Interfaces en langage naturel. Permettre aux utilisateurs d'exprimer ce qu'ils veulent en langage courant, plutôt que de naviguer à travers des menus et des filtres.

Là où ils ne se justifient pas

Résistez à l'IA pour tout ce qui doit être exact à chaque fois, tout ce pour quoi une mauvaise réponse formulée avec assurance est dangereuse ou coûteuse, ou tout ce qu'une règle simple gère déjà bien. Une regex, une table de correspondance ou une requête PostgreSQL est moins chère, plus rapide, plus fiable et infiniment plus facile à déboguer qu'un modèle pour un travail déterministe. Calculer un total, valider une adresse e-mail, appliquer une permission — rien de tout cela ne nécessite un LLM. En utiliser un à ces fins ajoute du coût, de la latence et un tout nouveau mode de défaillance, pour zéro gain. La décision la plus mûre que vous puissiez prendre dans un projet IA, c'est de dire : « cette partie n'a pas besoin d'IA. »

Choisir l'approche : prompting, RAG ou fine-tuning

Une fois que vous avez identifié un vrai besoin, choisissez la technique la plus légère qui le satisfait. Ne passez à plus de complexité que lorsque le palier précédent se révèle clairement insuffisant.

1. Prompting d'un modèle capable. Commencez toujours ici. Un prompt bien rédigé sur un modèle général performant résout une part surprenante des tâches, sans aucun entraînement ni pipeline de données. C'est la solution la moins chère à construire et la plus facile à faire évoluer.
2. Retrieval-augmented generation (RAG). Quand le modèle a besoin de connaître vos données — vos docs, vos données produit — récupérez le contenu pertinent et intégrez-le dans le prompt. C'est ainsi que vous ancrez les réponses sans rien réentraîner, et c'est le bon choix par défaut pour « répondre aux questions sur nos données ». La recherche vectorielle via pgvector (voir PostgreSQL pour les startups) maintient cela dans la base de données que vous utilisez déjà.
3. Fine-tuning. Uniquement lorsque vous avez besoin d'un style, d'un format ou d'un comportement spécifique que le prompting ne parvient pas à produire de manière fiable, et que vous disposez d'exemples de qualité pour l'entraînement. C'est l'option la plus coûteuse et la moins flexible — la plupart des produits n'en ont jamais besoin.

L'erreur est de commencer au troisième palier. Démarrez avec un prompt, ajoutez la récupération lorsque le modèle a besoin de vos données, et réservez le fine-tuning aux rares cas qui l'exigent vraiment.

Un exemple concret : transformer un vrai besoin en fonctionnalité

Les abstractions ont leurs limites, rendons cela concret. Imaginons qu'une équipe support passe des heures chaque jour à lire de longs fils de courriels clients et à renseigner manuellement un ticket avec le problème du client, son niveau d'urgence et le domaine produit concerné. Ce cas correspond exactement au bon profil : entrée non structurée, tâche fastidieuse pour un humain, tolérance à l'approximation puisqu'un agent examine chaque ticket de toute façon.

Voici comment les paliers décrits s'appliquent ici. Commencez par le prompting : envoyez le fil à un modèle capable et demandez-lui de renvoyer un résumé du problème, un niveau d'urgence parmi un ensemble fixe, et le domaine produit — en JSON structuré. Si le modèle doit connaître votre taxonomie produit spécifique, ajoutez la récupération : intégrez les entrées de catalogue pertinentes dans le prompt afin qu'il classe selon vos vraies catégories plutôt que de deviner. Vous n'auriez presque certainement jamais besoin de fine-tuning ici ; prompting et récupération suffisent.

Ensuite, concevez en anticipant les erreurs : le modèle propose les champs du ticket, l'agent les voit pré-remplis et valide ou corrige en un clic, et vous journalisez à la fois la suggestion et la version finale corrigée par l'humain. Ces corrections journalisées constituent votre jeu d'évaluation et, si vous en aviez un jour besoin, vos données de fine-tuning. La fonctionnalité fait gagner du temps réel dès le premier jour, se dégrade gracieusement en cas d'incertitude, et s'améliore de façon mesurable à mesure que vous apprenez — c'est exactement à quoi ressemble « livré », par opposition à une démo qui impressionne une fois et n'aide personne.

Concevoir en anticipant les erreurs du modèle

La différence fondamentale entre une démo et une fonctionnalité IA livrée réside dans la façon dont elle gère les erreurs. Les modèles sont probabilistes : ils produiront parfois une réponse fluide, assurée et totalement incorrecte. Une démo masque ce fait ; un vrai produit le prend en compte :

1. Maintenez un humain dans la boucle lorsque les enjeux sont élevés — l'IA propose, la personne valide. Cela transforme « l'IA a fait une erreur » en « l'IA a fait gagner du temps à quelqu'un qui a détecté le cas limite ».
2. Ancrez les réponses dans vos données via la récupération, afin que les réponses citent des sources réelles plutôt que de les inventer. Affichez la source ; permettez aux utilisateurs de vérifier.
3. Contraignez la sortie à des formats structurés (schémas JSON, enums) que vous pouvez valider avant d'agir. Rejetez ou relancez tout ce qui ne peut pas être parsé.
4. Dégradez gracieusement. Un clair « Je ne suis pas certain, voici ce que j'ai trouvé » vaut infiniment mieux qu'une hallucination assurée. Concevez délibérément l'état d'incertitude.

Coût, latence et confidentialité

Trois réalités pratiques déterminent si une fonctionnalité IA survit au contact de la production :

• Coût. Chaque appel coûte de l'argent et ce coût évolue avec l'usage. Mettez en cache de manière agressive, utilisez des modèles plus petits et moins chers pour les étapes simples, et n'envoyez pas plus de contexte que la tâche n'en nécessite.
• Latence. Les appels LLM sont lents comparés à une requête en base de données. Streamez les réponses pour que l'utilisateur voie la progression, effectuez le travail en arrière-plan lorsque c'est possible, et ne bloquez jamais toute l'interface sur un appel à un modèle.
• Confidentialité. Soyez délibéré sur les données utilisateurs qui quittent votre système et leur destination. Connaissez les conditions de rétention de données de votre fournisseur, et pour les domaines sensibles, réfléchissez à ce qui doit rester en interne.

Évaluer avant de faire confiance

On ne peut pas améliorer ce qu'on ne mesure pas, et « ça semblait bien sur quelques essais » n'est pas une mesure. Avant qu'une fonctionnalité IA soit livrée — et de manière continue par la suite — constituez un petit jeu d'évaluation : une collection d'entrées réelles associées à ce à quoi une bonne sortie ressemble. Exécutez-le chaque fois que vous modifiez un prompt, changez de modèle ou ajustez la récupération, et vous détecterez les régressions silencieuses qui affectent les fonctionnalités IA — ces situations où une modification qui améliore un cas en casse discrètement cinq autres.

Les évaluations n'ont pas besoin d'être élaborées. Même vingt à cinquante exemples représentatifs, évalués par une règle simple ou un second modèle jouant le rôle de juge, vous apprendront davantage que n'importe quelle quantité de vérifications manuelles ponctuelles. Les équipes qui maintiennent leurs fonctionnalités IA en bonne santé sur la durée sont celles qui traitent les prompts et les modèles comme du code susceptible de régresser, et les protègent en conséquence avec des tests. C'est la même discipline du « mesurer, pas deviner » qui distingue un MVP SaaS livré d'un simple projet de recherche.

Livrer petit, mesurer, étendre

Ne lancez pas une release « tout IA ». Choisissez une tâche à forte valeur, livrez-la derrière un flag à une partie de vos utilisateurs, et observez deux choses : les gens l'utilisent-ils, et continuent-ils à l'utiliser ? Mesurez le taux d'acceptation — la fréquence à laquelle les utilisateurs adoptent la suggestion de l'IA plutôt que de la modifier ou de la rejeter. Ce seul chiffre vous indique si la fonctionnalité apporte une vraie valeur ou n'est qu'une nouveauté dont l'usage explose au lancement pour stagner une semaine plus tard. C'est la même discipline que nous appliquons à tout lancement, comme dans notre guide MVP SaaS : livrer la plus petite chose réelle, mesurer, puis étendre à partir des données.

Construisez l'infrastructure permettant de changer de modèle et d'affiner les prompts sans redéploiement, car les deux évolueront constamment. Un service TypeScript léger et bien typé autour de l'appel au modèle — avec journalisation, relances, validation de la sortie structurée et un petit jeu d'évaluation d'exemples réels — s'amortit dès la première fois où vous devez changer de fournisseur ou qu'un prompt régresse silencieusement. Traitez les prompts et le choix du modèle comme de la configuration, pas comme des constantes codées en dur.

Si vous souhaitez ajouter une IA que vos utilisateurs conservent vraiment, en partant d'un vrai besoin plutôt que du battage médiatique, parlons-en.