Depuis deux ans, à peu près tous les produits SaaS du marché ont collé un bouton "Ask AI" quelque part dans leur interface. Le résultat est connu : la plupart de ces features sont peu utilisées, jamais critiques, et font sourire les équipes en interne autant qu'à l'extérieur.

Le problème n'est pas la qualité des modèles. GPT-4, Claude, Gemini sont remarquables. Le problème est architectural.

La feature greffée contre la couche structurante.

Une feature greffée, c'est une fonctionnalité IA branchée sur un produit qui a été conçu sans elle. L'utilisateur doit explicitement aller la chercher, formuler un prompt, attendre une réponse, et recopier le résultat ailleurs. C'est un détour, pas un raccourci.

Une couche structurante, c'est l'inverse. Les modèles font partie de la base de données conceptuelle du produit. Ils interviennent en amont, pas en aval. Ils transforment la donnée brute en donnée structurée avant même qu'elle atteigne l'utilisateur.

Concrètement, dans un outil de pré-deal pour fonds d'investissement, ça change tout. Une feature greffée vous laisse écrire "résume cette entreprise" dans un chat. Une couche structurante détecte automatiquement les signaux faibles, classe les cibles selon votre thèse d'investissement, et vous présente un dashboard où l'IA a déjà fait le travail invisible.

Trois principes de conception.

1. Les modèles structurent la donnée, pas la sortie.

La tentation est forte de demander au modèle de produire le rendu final — un texte, un résumé, une recommandation. C'est une erreur. Le modèle doit produire de la donnée structurée que le produit traite ensuite normalement.

Au lieu de "rédige un compte-rendu de cette réunion", on demande "extrais les engagements pris, les blocages identifiés, et les prochaines actions, au format JSON avec ces clés". Le rendu visuel est ensuite construit par le code, pas par le modèle. C'est plus fiable, plus testable, plus maintenable.

2. Le prompt est un contrat, pas une conversation.

Un prompt en production n'est pas un dialogue improvisé. C'est un contrat précis qui définit les inputs autorisés, le format de sortie, les cas limites, et les comportements en cas d'échec. On le versionne, on le teste, on le monitore comme du code.

3. L'humain garde la main sur la décision.

Les modèles sont remarquables pour structurer, classer, extraire, suggérer. Ils sont mauvais pour décider seuls dans des contextes à fort enjeu. Le bon design IA donne au modèle le rôle de préparateur de décision, et garde la décision finale chez l'humain — sauf pour les actions à très faible risque qu'on automatise complètement.

L'erreur que tout le monde fait.

Vouloir tout faire passer par un chat. Le chat est l'interface naturelle pour explorer un sujet inconnu. Ce n'est pas l'interface naturelle pour faire un travail récurrent. Si votre utilisateur sait ce qu'il veut faire — qualifier une cible, générer un courrier, mapper un compte-rendu — il a besoin d'une interface dédiée à cette tâche, avec l'IA en dessous, pas d'un prompt vide.

Un produit IA bien conçu ressemble à un produit normal qui se trouve être beaucoup plus rapide et précis. Pas à un chatbot.

Ce que ça implique en pratique.

Un produit IA-native coûte plus cher à concevoir au départ. Il faut faire de la recherche utilisateur sectorielle profonde, écrire des prompts robustes, mettre en place des évaluations, gérer la latence et les coûts d'inférence. Mais il vaut beaucoup plus en aval, parce qu'il fait vraiment le travail au lieu d'ajouter un détour.

Pour un opérateur qui choisit entre intégrer ChatGPT à son outil existant ou refondre son outil avec l'IA dans la conception, la question n'est pas le coût immédiat. C'est le coût total sur trois ans, et la position concurrentielle qu'on veut tenir.