AI Engineering

Livrer des fonctionnalités IA auxquelles les utilisateurs font vraiment confiance

8 min de lecture14 juillet 2026

Ajouter de l'IA à un produit est facile. Ajouter une IA que les gens continuent d'utiliser, beaucoup moins.

La démo fonctionne toujours. Vous branchez un appel LLM, vous collez un prompt bien tourné, et la première réponse ressemble à de la magie. Puis les vrais utilisateurs arrivent, et la magie se transforme en tickets de support : le modèle invente une règle qui n'existe pas, la réponse met onze secondes, et la facture de fin de mois est quatre fois supérieure à vos prévisions.

J'ai livré des fonctionnalités IA en production pour des clients sur trois continents. Voici ce qui distingue réellement celles qui survivent de celles qu'on retire discrètement deux mois plus tard.

La confiance est un problème de design avant d'être un problème de modèle

Les utilisateurs n'évaluent pas votre modèle. Ils évaluent leur capacité à le prévoir.

Une fonctionnalité juste à 95 % mais incapable de signaler les 5 % restants est pire qu'une fonctionnalité juste à 85 % qui annonce son incertitude. La première apprend à se méfier de tout. La seconde apprend quand vérifier.

Trois choses qui achètent de la confiance à bas prix :

Montrez la source. Si la réponse vient d'un document, affichez le lien. Un utilisateur qui peut vérifier cesse d'en avoir besoin.
Autorisez le modèle à dire « je ne sais pas ». Précisez-le dans le prompt système et prévoyez un état d'interface pour ce cas. Un état vide n'est pas un échec — une réponse fausse et assurée, si.
Rendez l'IA réversible. Ne laissez jamais un modèle écrire en base sans annulation visible par un humain. « Suggéré » vaut presque toujours mieux qu'« appliqué ».

Streamez tout, systématiquement

Un LLM qui met six secondes à produire un paragraphe paraît cassé. Le même appel, streamé token par token, paraît rapide — alors que la durée totale est identique.

C'est le changement au meilleur rapport effort/résultat sur un problème de qualité perçue, et il ne coûte presque rien dans les frameworks modernes. Streamez la réponse, affichez la sortie partielle au fil de l'eau, et donnez à l'utilisateur quelque chose à lire pendant que le reste arrive.

Si le streaming est impossible, affichez au minimum ce que fait le système : « Recherche dans vos documents… », « Rédaction d'une réponse… ». Le silence est l'endroit où meurt la patience.

Contraignez la sortie, puis validez-la

Le texte libre est un cauchemar à exploiter. Demandez une sortie structurée et validez-la avant qu'elle n'atteigne votre interface.

const ResultSchema = z.object({
  summary: z.string().max(500),
  confidence: z.enum(['high', 'medium', 'low']),
  sources: z.array(z.string().url()).max(5),
})

const parsed = ResultSchema.safeParse(JSON.parse(raw))
if (!parsed.success) {
  // Un seul réessai, puis repli sur un chemin sans IA — jamais de sortie non validée.
  return fallbackResponse()
}

Deux règles qui m'ont sauvé à répétition :

Prévoyez toujours un chemin de repli sans IA. Si le modèle est indisponible, limité en débit ou renvoie n'importe quoi, la fonctionnalité doit se dégrader vers quelque chose d'utile, pas vers un écran d'erreur.
Ne traitez jamais la sortie du modèle comme une instruction. Si ce texte revient dans un prompt, une commande shell ou du SQL, vous avez créé une faille d'injection de prompt. Traitez la sortie du modèle comme vous traitez une saisie utilisateur.

Le coût est une décision produit, pas un détail d'infrastructure

Le coût des tokens ne se comporte pas du tout comme celui des serveurs. Un seul utilisateur intensif avec un long historique peut coûter plus cher qu'un millier d'utilisateurs occasionnels, car chaque tour renvoie l'intégralité du contexte.

Des leviers concrets qui fonctionnent :

Mettez en cache agressivement. Les prompts système répétés et les documents de référence peuvent être mis en cache chez la plupart des fournisseurs, ce qui réduit fortement le coût de la partie stable du contexte.
Élaguez le contexte volontairement. N'envoyez pas la conversation entière indéfiniment. Résumez les échanges anciens ou gardez une fenêtre glissante.
Adaptez le modèle à la tâche. Classification, extraction et routage n'exigent pas votre modèle le plus puissant. Réservez-le aux tâches où la qualité est visible.
Fixez des limites par utilisateur avant le lancement, pas après la facture.

Évaluez avant de livrer, et continuez d'évaluer

L'habitude qui sépare les équipes livrant une IA fiable de celles livrant des démos : elles ont un jeu de tests.

Il n'a rien de sophistiqué. Vingt à cinquante entrées réelles avec la sortie que vous jugez correcte, rejouées à chaque modification de prompt, suffisent à détecter la régression où « améliorer » le prompt pour un cas en casse six autres en silence. Sans cela, vous modifiez le comportement en production au feeling.

La checklist d'avant-lancement

Avant qu'une fonctionnalité IA n'atteigne de vrais utilisateurs, je parcours cette liste. Chaque ligne existe parce que l'avoir sautée a coûté de l'argent à quelqu'un.

Le dernier point compte plus qu'il n'y paraît. Quand une fonctionnalité IA dérape à 2 h du matin, la différence entre un drapeau de configuration et un déploiement d'urgence, c'est la différence entre un haussement d'épaules et une panne.

Le résumé honnête

La partie IA n'est presque plus la partie difficile. Le difficile, c'est l'ingénierie autour : streaming, validation, replis, plafonds de coûts, et une interface honnête sur ce que le système ignore.

Construisez cela, et la fonctionnalité gagne sa place dans le produit. Sautez ces étapes, et vous avez livré une démo très coûteuse.