La plupart des projets d’IA générative échouent de la même façon.
Pas à cause d’une mauvaise ingénierie. Pas à cause du mauvais modèle choisi. Ils échouent parce que l’équipe a pris une série de décisions dans les deux premières semaines qui les a enfermés dans une voie qui ne fonctionne pas. Le temps que les problèmes remontent à la surface, la base de code a six mois et personne ne veut réécrire l’architecture centrale.
Nous avons travaillé sur des produits d’IA générative dans la fintech, la healthtech et les SaaS d’entreprise. Les patterns d’échec se répètent avec une consistance inconfortable. Des secteurs différents, des tailles d’équipes différentes, des budgets différents. Les mêmes erreurs.
Voici celles qui reviennent le plus souvent.
1. Commencer par le modèle au lieu du problème
La première étape la plus courante dans un projet d’IA générative : quelqu’un choisit GPT-4o ou Claude, obtient une clé API et commence à construire une démo. La démo est impressionnante. La direction s’enthousiasme. Maintenant l’équipe doit déterminer quel problème elle résout réellement.
C’est à l’envers.
Le modèle est un détail d’implémentation. Le problème définit l’architecture. Une fonctionnalité de résumé de documents a des exigences complètement différentes d’un agent de support conversationnel. L’un a besoin d’un débit élevé et d’un traitement par lots. L’autre a besoin d’une latence inférieure à la seconde et d’une gestion de session. Choisir le modèle en premier signifie que vous avez déjà contraint votre architecture avant de comprendre les contraintes qui comptent vraiment.
Les équipes qui livrent avec succès commencent par un workflow spécifique, un utilisateur spécifique et un résultat spécifique. Elles définissent ce que “bon” signifie en termes concrets avant d’écrire une seule ligne de code d’inférence. Alors le choix du modèle devient évident, parce que les exigences vous disent ce dont vous avez besoin.
2. Pas d’infrastructure d’évaluation
C’est celui qui tue les projets en silence.
Sans suite d’évaluation, vous ne pouvez pas mesurer la qualité de vos sorties. Vous ne pouvez pas comparer les prompts. Vous ne pouvez pas faire des tests de régression après une mise à jour de modèle. Vous ne pouvez pas quantifier si votre pipeline de récupération aide vraiment. Vous livrez des changements basés sur l’intuition.
Construire une infrastructure d’évaluation n’est pas un travail glamour. Ça signifie créer des jeux de données de test avec des réponses correctes connues, construire des rubriques de notation (automatisées et humaines), et exécuter des évaluations sur chaque changement. La plupart des équipes sautent ça parce que la première version “fonctionne bien” dans les tests manuels.
Puis le fournisseur de modèle publie une nouvelle version. Ou quelqu’un ajuste un system prompt. Ou le contexte de récupération change. La qualité des sorties se dégrade, mais personne ne le remarque pendant des semaines parce qu’il n’y a pas de signal automatisé. Au moment où un client se plaint, le dommage est déjà fait.
La suite d’évaluation doit exister avant le premier déploiement en production. Pas après. Traitez-la comme votre suite de tests pour le logiciel traditionnel : si elle n’existe pas, le système n’est pas prêt pour la production.
3. Traiter les prompts comme le produit
Le prompt engineering est un point de départ. C’est une compétence utile pour le prototypage et l’expérimentation. Ce n’est pas une architecture.
Un système d’IA générative en production a besoin de pipelines de récupération, de validation des sorties, de garde-fous pour les réponses hors sujet ou nuisibles, d’un comportement de repli quand le modèle échoue, de stratégies de cache et d’un parsing structuré des sorties. Le prompt représente peut-être 10% du système. Les équipes qui investissent tout leur effort dans la création du prompt parfait et négligent tout ce qui l’entoure finissent avec un système qui fonctionne dans les démos et s’effondre en production.
L’écart entre “ça fonctionne dans le playground” et “ça fonctionne à grande échelle avec de vrais utilisateurs” est là où vit la plupart de l’ingénierie. Cet écart inclut la gestion des cas limites que le modèle rate, la gestion des fenêtres de contexte à mesure que les conversations grandissent, et la construction de la couche d’observabilité qui vous dit ce qui se passe en production.
Si tout votre effort de développement d’IA générative vit dans des templates de prompts, vous n’avez pas construit un produit. Vous avez construit un wrapper.
4. Sous-estimer la latence
Les utilisateurs n’attendront pas 8 secondes pour une réponse. Ils n’attendront pas 5 secondes. Dans la plupart des contextes produit, tout ce qui dépasse 2 secondes semble cassé.
Ça devient un vrai problème avec les chaînes multi-étapes. Si votre architecture route une requête utilisateur à travers une étape de classification (500ms), puis la récupération (300ms), puis la génération (2s), puis la validation de la sortie (400ms), vous êtes déjà à 3,2 secondes. Ajoutez la latence réseau et vous approchez les 4 secondes. Multipliez par le nombre d’étapes dans un workflow d’agent complexe.
La latence s’accumule. Chaque étape supplémentaire ajoute du temps que les utilisateurs ressentent.
La solution n’est pas seulement des modèles plus rapides. C’est architectural. Diffusez les réponses pour que l’utilisateur voie les tokens apparaître immédiatement. Exécutez les étapes indépendantes en parallèle au lieu de séquentiellement. Mettez en cache agressivement pour les requêtes répétées. Pré-calculez là où c’est possible. Concevez l’UX autour de la vitesse perçue, pas seulement la vitesse réelle.
Certains des meilleurs produits d’IA générative semblent rapides non parce que le modèle est rapide, mais parce que l’équipe a conçu chaque interaction pour minimiser le temps d’attente perçu. C’est un problème d’ingénierie et de design, pas un problème de modèle.
5. Ignorer la modélisation des coûts jusqu’en production
En développement, vous faites peut-être 100 appels API par jour. À 0,01 $ par requête, c’est un dollar. Personne ne pense aux coûts.
Puis vous lancez. Soudainement vous traitez 10 000 requêtes par jour. Votre requête moyenne utilise 4 000 tokens d’entrée et 1 000 tokens de sortie. Avec un modèle frontier, vous regardez 0,04 à 0,08 $ par requête. C’est 400 à 800 $ par jour. 12 000 à 24 000 $ par mois. Pour une seule fonctionnalité.
Et c’est la baseline. Ajoutez de la génération augmentée par récupération avec de grandes fenêtres de contexte et vos coûts doublent ou triplent. Ajoutez des workflows d’agents multi-étapes où une seule action utilisateur déclenche 4 à 5 appels de modèle et vous êtes à 0,20 à 0,30 $ par interaction utilisateur.
Les équipes qui gèrent bien ça font le calcul des tokens tôt. Elles modélisent les coûts par requête à grande échelle pendant la phase de conception. Elles prennent des décisions délibérées sur où utiliser les modèles frontier et où un modèle plus petit et moins cher est suffisant. Elles intègrent le monitoring des coûts dans leur stack d’observabilité dès le premier jour, pas comme une réflexion après coup quand la facture mensuelle arrive.
Une société de développement d’IA générative qui ne parle pas de modélisation des coûts dans la première semaine ne pense pas à la production.
6. Recruter un “Head of AI” avant de comprendre le problème
Le pattern : une entreprise décide que l’IA générative est stratégique. Elle embauche un “Head of AI” ou “VP of AI” senior pour diriger l’effort. Cette personne passe 3 à 4 mois à construire un deck de stratégie, évaluer des fournisseurs et assembler une équipe. Six mois plus tard, rien n’a été livré.
Ce n’est pas une critique des leaders IA. Le problème est le séquençage. Le recrutement basé sur le titre avant le cadrage basé sur le problème signifie que vous vous êtes engagé dans une structure organisationnelle avant de savoir ce que vous construisez. Le Head of AI pourrait être brillant en infrastructure ML mais votre problème a besoin d’un ingénieur produit qui comprend l’architecture des applications LLM. Ou vice versa.
Les entreprises qui bougent le plus vite commencent par un problème spécifique et une petite équipe qui peut livrer quelque chose en semaines, pas en mois. Elles déterminent quelle expertise elles ont vraiment besoin en construisant, pas en planifiant. Le recrutement de leadership vient après que vous avez compris la forme du travail, pas avant.
Si vous avez besoin d’une expertise IA intégrée dans votre équipe pour déterminer la bonne approche, faites venir des constructeurs expérimentés en premier. La stratégie émerge de la construction. Pas l’inverse.
7. Construire un chatbot quand vous avez besoin d’un workflow
L’interface utilisateur par défaut pour l’IA générative est un chat. C’est la voie de la moindre résistance. Ajoutez une zone de saisie en bas, diffusez la réponse, et appelez ça un produit.
Mais la plupart des problèmes métier ne se mappent pas à des conversations. Un workflow de révision de conformité a besoin d’entrées structurées, d’étapes de révision définies et de pistes d’audit. Un processus de souscription a besoin de champs de formulaire, d’arbres de décision et de portes d’approbation humaine. Un pipeline de génération de contenu a besoin de templates, de règles de marque et de révision éditoriale.
Forcer ces workflows dans une interface de chat crée une pire expérience utilisateur, pas une meilleure. Les utilisateurs doivent taper des instructions au lieu de cliquer à travers un processus guidé. Ils doivent se souvenir de quoi demander au lieu de suivre un flux structuré. La gestion des erreurs devient “demandez à nouveau d’une façon différente.”
Les meilleurs produits d’IA générative ne ressemblent pas du tout à ChatGPT. Ils ressemblent à des outils dédiés où l’IA est invisible, faisant son travail derrière des interfaces structurées qui guident les utilisateurs dans le processus. L’IA gère le travail cognitif difficile. L’UI gère le workflow humain autour de lui.
Le chat est parfois la bonne réponse. Support client, recherche ouverte, assistants de codage. Pour la plupart des cas d’usage en entreprise, c’est la réponse paresseuse.
8. Pas de humain-dans-la-boucle dès le premier jour
Chaque système d’IA générative se trompe. Les modèles hallucinent. Ils mal interprètent des entrées ambiguës. Ils génèrent des sorties qui sont techniquement correctes mais contextually inappropriées. Ce n’est pas un bug qui se corrige avec de meilleurs prompts. C’est une propriété fondamentale des systèmes probabilistes.
L’erreur n’est pas de s’attendre à ce que le modèle soit imparfait. L’erreur est de ne pas concevoir en conséquence.
Les systèmes qui ne peuvent pas escalader vers un humain quand la confiance est faible échoueront publiquement. Un agent IA qui envoie une réponse incorrecte à un client sans étape de révision ne crée pas seulement une mauvaise expérience. Il crée un problème de confiance difficile à récupérer. Une mauvaise réponse vue par la mauvaise personne peut tuer l’adoption de tout le produit.
Le humain-dans-la-boucle n’est pas une phase que vous ajoutez plus tard quand le système est “assez mature.” C’est une décision architecturale qui façonne la façon dont vous construisez le système. Elle détermine votre conception de queue, votre logique de notification, vos budgets de latence pour différents niveaux de confiance, et votre UX pour l’interface de révision. L’ajouter après le lancement signifie refaire la moitié du système.
L’implémentation pratique varie. Les sorties à haute confiance peuvent passer directement. Les sorties à confiance moyenne sont marquées pour révision asynchrone. Les sorties à faible confiance bloquent jusqu’à l’approbation d’un humain. Les seuils et la logique de routage deviennent certains des IP les plus précieux du système, parce qu’ils définissent la frontière entre l’automatisation et le jugement humain pour votre domaine spécifique.
Les équipes qui sautent cette étape tendent à compenser en rendant le modèle trop conservateur, ce qui annule l’objectif. Ou elles lancent sans garde-fous et gèrent les conséquences. Ni l’une ni l’autre approche ne fonctionne à grande échelle.
Ce que le succès ressemble
Les entreprises qui livrent des produits d’IA générative avec succès partagent quelques traits.
Elles commencent par un problème à portée étroite et une définition claire du succès. Pas “ajouter de l’IA au produit” mais “réduire le temps pour générer un rapport de conformité de 4 heures à 20 minutes, avec 95% de précision sur les citations réglementaires.” La spécificité force de bonnes décisions d’architecture.
Elles construisent une infrastructure d’évaluation avant de construire des fonctionnalités. Elles savent comment mesurer la qualité, donc elles peuvent l’améliorer systématiquement au lieu de deviner.
Elles traitent le coût et la latence comme des contraintes de conception de premier ordre, pas comme des réflexions après coup. Les budgets de tokens et les objectifs de temps de réponse vivent aux côtés des exigences fonctionnelles dans la spec.
Elles recrutent des constructeurs, pas des stratèges. Le premier recrutement (ou la première équipe externe) livre quelque chose à de vrais utilisateurs en quelques semaines. La stratégie vient de ce qu’elles apprennent, pas d’un playbook pré-construit.
Et elles conçoivent pour les humains dans la boucle dès le premier jour. Chaque sortie générée par l’IA a un chemin vers la révision humaine quand la confiance est faible. Chaque agent peut escalader. Chaque workflow inclut la sortie de secours qui maintient le système digne de confiance quand le modèle se trompe.
Rien de tout ça n’est théorique. Ce sont des patterns vus dans de vraies bases de code, de vraies structures d’équipes, de vrais lancements de produits. Les entreprises qui évitent ces erreurs ne sont pas nécessairement plus intelligentes ou mieux financées. Elles ont juste vu à quoi ressemble l’échec, soit en direct soit à travers quelqu’un dans l’équipe qui l’a vécu.
Le développement d’IA générative est encore assez nouveau pour que la plupart des entreprises apprennent en échouant. Les échecs n’ont pas à être coûteux. La plupart sont évitables si vous savez quoi surveiller et construisez avec les réalités de production à l’esprit dès la première semaine.
Besoin d’aide pour amener votre premier produit d’IA générative en production sans les erreurs habituelles ? Parlons-en.