Une démo de chat sur un modèle de langage se construit en une semaine environ. Les ennuis commencent après, quand cette même fonctionnalité doit tourner sur des données de production, sous un trafic réel, avec un coût prévisible et sans hallucinations qui mettent la marque en difficulté. Pour un CTO, un Head of Product ou un Head of AI, la vraie question n’est pas s’il faut ajouter de l’IA, mais où, comment et avec quelles mains le faire pour que la fonctionnalité survive au contact des utilisateurs. C’est à ce moment-là que les fonctionnalités IA d’un produit cessent d’être une démo pour devenir un morceau d’architecture à maintenir des années.
D’après notre expérience, le plus difficile n’est pas l’intégration au modèle mais l’ingénierie autour : choisir les données, évaluer la qualité, maîtriser le coût et traiter la confidentialité. Au sein du groupe RITS, nous construisons une compétence IA/Data réelle, avec nos équipes IA/LLM/data, et nous avons livré des projets GenAI, RAG et LLM, dont un assistant de connaissance fondé sur l’IA pour un client du secteur de l’assurance. Nous portons cette expérience dans les produits tech, en pourvoyant les rôles qui manquent en général côté client.
Où l’IA apporte-t-elle réellement de la valeur dans un produit ?
Avant la question du modèle vient celle de l’endroit. L’IA se rentabilise là où un produit comporte beaucoup de texte non structuré ou de travail cognitif répétitif, pas partout. La valeur réelle apparaît généralement dans quelques schémas :
- la recherche et la réponse aux questions dans une documentation, une base de connaissance ou un historique de tickets,
- le résumé et l’extraction à partir de longs documents, d’e-mails et de transcriptions,
- l’aide à la décision pour un opérateur : suggestions, classification, premiers brouillons de réponses,
- l’automatisation d’étapes fastidieuses dans un processus aujourd’hui fait à la main.
Une première fonctionnalité bien choisie a toujours un point commun : vous pouvez la mesurer et vous pouvez revenir en arrière si elle échoue. C’est par là que nous commençons, car cela limite le risque et gagne la confiance de l’organisation pour les étapes suivantes.
En quoi les fonctionnalités LLM et RAG diffèrent-elles dans un produit ?
Cette distinction commande à la fois l’architecture et le coût. Un LLM seul travaille sur ce que le modèle « sait » de son entraînement et sur ce que vous mettez dans le prompt : il excelle à générer, reformuler et classer, mais il ne connaît pas vos données. Le RAG (retrieval-augmented generation) ajoute une couche de recherche : il trouve d’abord les bons fragments de votre connaissance, et le modèle répond ensuite à partir d’eux, avec une référence à la source.
En pratique, la plupart des fonctionnalités produit qui aident vraiment un utilisateur relèvent du RAG, pas d’un LLM nu. La raison est prosaïque : une entreprise veut une réponse ancrée dans ses propres documents et vérifiable, pas dans la connaissance générale du modèle. C’est exactement le schéma que nous avons utilisé dans l’assistant de connaissance du client assurance, où le modèle devait répondre à partir d’une base précise, propriété de l’entreprise, au lieu de deviner.
Comment intégrer et évaluer les modèles d’IA ?
L’intégration est la partie la plus simple. La plus difficile est l’évaluation, la réponse à la question de savoir si une fonctionnalité est assez bonne pour être livrée. Sans elle, l’équipe travaille à l’aveugle et ne réagit qu’aux plaintes des utilisateurs.
- Un jeu de test de questions réelles et de réponses attendues, construit avec les experts métier.
- Des métriques de qualité adaptées à la tâche : pertinence de la réponse, citation des sources, taux d’hallucination.
- Une comparaison des modèles et des configurations (modèles, prompts, paramètres différents) sur le même jeu, au lieu d’un choix à l’intuition.
- Une régression avant chaque livraison, pour qu’un changement de prompt ne casse pas ce qui fonctionnait déjà.
Nous traitons le modèle comme un composant testé et versionné, pas comme une boîte magique. La décision de livrer repose ainsi sur des chiffres, et non sur une démo chanceuse.
Comment insérer des agents IA dans les processus de delivery et dans le produit ?
Un agent IA est un modèle qui ne se contente pas de répondre mais qui agit : il recourt à des outils, appelle des API, enchaîne plusieurs actions en un flux. Dans un produit, il fonctionne là où la tâche a un but clair et un résultat mesurable, par exemple le traitement d’un ticket ou la préparation d’un premier brouillon de document.
Nous utilisons aussi les agents de notre côté, dans le processus de delivery, pour accélérer les parties routinières du travail d’ingénierie. Le principe est le même dans les deux cas : un agent reçoit un périmètre étroitement défini et des limites de droits strictes, pas les pleins pouvoirs. Plus une étape est autonome, plus les contrôles autour d’elle doivent être solides, car le coût d’une erreur croît plus vite que le confort de l’automatisation.
Comment maîtriser la qualité des prompts et des sorties ?
Un prompt n’est pas une note : c’est un artefact produit que l’on maintient comme du code. Nous le gardons donc dans un dépôt, le versionnons et le testons, au lieu de le laisser dans la tête de quelques personnes. Autour des sorties, nous construisons une couche de sécurité qui intercepte ce que le modèle ne devrait pas renvoyer.
- Le versionnage des prompts, relié aux résultats d’évaluation.
- La validation du format de sortie (par exemple un JSON imposé), pour que le résultat puisse être traité sans risque.
- Des règles de content safety et des filtres pour les données sensibles, en entrée comme en sortie.
- Un monitoring en production : journalisation des requêtes, des coûts et des signaux de réponses de faible qualité.
Cette couche décide si une fonctionnalité IA est reproductible plutôt que dépendante de la chance sur une requête donnée.
Combien cela coûte-t-il, et comment traiter la sécurité et la confidentialité des données ?
Le coût de l’IA dans un produit n’est pas une facture unique mais la somme des appels au modèle, du stockage vectoriel et de la maintenance. Nous pouvons le rendre réaliste dès la conception, en adaptant le modèle à la tâche (plus petit et moins cher là où cela suffit), en raccourcissant les prompts, en mettant en cache les réponses répétitives et en décidant de ce qui doit seulement atteindre un modèle.
Nous traitons la sécurité et la confidentialité comme une condition d’entrée, et non comme un complément. Quand nous travaillons sur les données d’un client, nous établissons tôt où les données sont physiquement traitées, si elles partent vers un modèle public ou une variante privée, et comment elles sont anonymisées et conservées. Dans les projets régulés, comme en assurance, ce sont ces décisions, et non le choix du modèle, qui déterminent si une fonctionnalité peut seulement être livrée.
Pourquoi les fonctionnalités IA ont-elles besoin d’un humain dans la boucle ?
Parce qu’un modèle peut être sûr de lui alors même qu’il se trompe. Pour les fonctionnalités qui touchent à l’argent, au droit, à la santé ou à la réputation de la marque, nous concevons l’humain dans la boucle comme un choix délibéré, pas comme un garde-fou ajouté à la fin. En pratique, cela signifie que pour les réponses à faible confiance le produit propose au lieu d’agir, et laisse la dernière étape à une personne. Ce dispositif permet de livrer l’IA plus vite et plus sûrement, car l’organisation n’a pas à faire confiance au modèle à cent pour cent du jour au lendemain.
Quelles compétences IA apportons-nous au projet ?
Même si nous n’avons pas construit exactement votre type de produit, nous fournissons des personnes qui l’ont déjà fait sur d’autres projets GenAI/RAG/LLM. Nous façonnons l’équipe autour de la tâche réelle, et non « au cas où » :
- des ingénieurs AI/ML et LLM qui construisent les fonctionnalités, les prompts et la couche RAG,
- des data engineers qui nettoient et préparent la connaissance pour la recherche,
- des architectes qui relient le modèle, le backend et l’infrastructure en un ensemble maintenable,
- des DevOps/MLOps qui portent les déploiements, le monitoring et les coûts des modèles.
Nous intégrons cette équipe à votre produit en renfort d’équipe ou en équipe dédiée, sous votre direction, en ajoutant les compétences exactement là où elles manquent.
Comment procédons-nous chez RITS ?
Nous le faisons en tant que partenaire nearshore depuis la Pologne, avec une compétence IA/Data réelle au sein du groupe RITS (dont nos équipes IA/LLM/data). Nous commençons par une fonctionnalité mesurable, pas par une plateforme IA entière d’un coup. Nous la construisons sur le RAG et les données propres du client, avec l’évaluation et le monitoring dès le départ, et non après les premières plaintes. Nous fixons la confidentialité et la sécurité des données avant le premier appel au modèle, car dans les projets régulés elles décident si une fonctionnalité peut être livrée. Nous avons livré des projets GenAI/RAG/LLM, dont un assistant de connaissance fondé sur l’IA pour un client du secteur de l’assurance, et nous portons cette expérience dans les produits tech, en pourvoyant les rôles manquants avec des personnes éprouvées.
Par où commencer pour ajouter des fonctionnalités IA à un produit ?
Commencez par un problème utilisateur concret que vous pouvez mesurer, et par la question de la connaissance dont l’IA a besoin pour répondre sensément. Cela décide si vous avez besoin d’un LLM seul ou d’un RAG, des données à préparer et des rôles à pourvoir. Si vous hésitez sur le modèle de collaboration par lequel démarrer, nous avons traité les différences dans notre article sur les modèles de collaboration IT.
Vous ajoutez des fonctionnalités IA (LLM/RAG) à votre produit ? Parlons-en - nous adapterons les compétences et l’architecture à votre cas.
Ajoutons ensemble des fonctionnalités IA (LLM/RAG) à votre produit