Réfléchir avant de construire : cadrer un problème d'IA

L'équipe support d'un éditeur de logiciels de taille moyenne a passé trois mois à construire un chatbot IA. Ils l'ont lancé, et en deux semaines les clients étaient furieux. Le bot donnait des réponses vagues, tournait en boucle, et agaçait les gens plus qu'avant. Quand l'équipe a enfin regardé les données, elle a trouvé quelque chose de gênant : 80 % des questions entrantes étaient les mêmes 15 questions, toutes traitées dans leur documentation d'aide existante. Les clients n'arrivaient simplement pas à *trouver* ces docs.

Ils n'avaient pas besoin d'un chatbot. Ils avaient besoin d'une meilleure recherche.

C'est la manière la plus courante dont les projets d'IA échouent. La technologie n'est pas coupable ; le cadrage l'est. Quelqu'un dit « ajoutons de l'IA », et l'équipe commence à construire avant que personne ne demande « quel problème résolvons-nous au fond ? »

Le piège : penser solution d'abord

« Ajoutons un chatbot » est une solution. Ce n'est pas un problème.

Quand vous partez de la solution, vous sautez l'étape la plus importante : comprendre ce qui est cassé et pour qui. Vous finissez par construire quelque chose d'impressionnant dont personne n'avait besoin.

Penser solution d'abord, ça ressemble à ça :

• « Utilisons l'IA pour résumer nos rapports. »
• « On devrait construire un agent IAagent IALogiciel qui poursuit un objectif seul : il planifie, utilise des outils et agit avec une intervention humaine limitée.Voir la définition complète → pour les ventes. »
• « On peut ajouter un GPT sur notre site ? »

Penser problème d'abord, ça ressemble à ça :

• « Nos managers passent 4 heures par semaine à lire des rapports qu'ils survolent de toute façon. »
• « Les commerciaux perdent 30 minutes par appel à chercher des spécifications produit. »
• « Les nouveaux visiteurs n'arrivent pas à comprendre ce que fait notre produit en moins de 10 secondes. »

Notez la différence. La seconde liste décrit une douleur, qui la ressent, et dans quelle mesure. Cela vous donne quelque chose à mesurer et à résoudre. La première liste, c'est un outil en quête d'un usage.

Une méthode de cadrage simple

Avant de construire quoi que ce soit, notez quatre choses. Cela prend 20 minutes et vous économise des mois.

1. La tâche

Quelle est la tâche précise que quelqu'un cherche à accomplir ? Soyez concret.

Mauvais : « Améliorer le support client. »

Bon : « Aider un client à trouver la réponse à une question courante sans attendre un humain. »

2. qui a le problème

Nommez la personne réelle. Un client agacé à 23 h ? Un agent support surchargé ? Un manager noyé sous les tickets ? Chacun mène à une solution différente.

3. comment vous saurez que ça a marché

Nous voyons comment définir un critère de succès mesurable et auditer vos données en détail dans la leçon « Cadrage : données et critères de succès ».

4. la chose la plus simple qui pourrait marcher

C'est le point clé. Forcez-vous à demander : **quelle est la *moindre* quantité de technologie qui résout le problème** ? Souvent la réponse n'implique aucune IA, ou une toute petite part.

Pour l'équipe support, le correctif le plus simple était une barre de recherche intelligente sur leur documentation existante. Moins cher, plus rapide, et ça a vraiment marché.

Reprenons l'exemple du support

Refaisons le projet de chatbot raté, mais correctement.

La tâche : un client veut la réponse à une question de routine (réinitialisation de mot de passe, date de facturation, limites d'export) tout de suite.

Qui : des clients, souvent hors heures ouvrées, qui préfèrent se servir eux-mêmes plutôt qu'attendre.

Métrique de succès : 50 % des questions courantes résolues sans humain, mesuré par la baisse du volume de tickets.

La chose la plus simple qui pourrait marcher : un champ de recherche qui comprend les questions en langage courant et renvoie le bon article d'aide. Pas une conversation. Une recherche.

C'est là qu'une technique appelée recherche sémantiquerecherche sémantiqueRecherche qui repose sur le sens et l'intention plutôt que sur les mots exacts, reliant requête et résultat même sans mots communs.Voir la définition complète → trouve sa place. La recherche sémantique consiste à faire correspondre par *sens*, pas seulement par mots-clés. Un client tape « je ne peux pas me connecter » et l'outil trouve l'article intitulé « Réinitialiser votre mot de passe », alors qu'aucun de ces mots ne correspond. Une recherche par mots-clés classique passerait à côté.

Vous pouvez construire une version basique avec un modèle d'embedding (un outil qui transforme du texte en une liste de nombres représentant son sens, de sorte que les sens proches se retrouvent proches). Voici un exemple minimal avec l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → d'OpenAI en Python :

from openai import OpenAI
client = OpenAI()

# Vos articles d'aide existants
docs = [
    "Resetting your password: click Forgot Password on the login screen.",
    "Your billing date is the day you first subscribed.",
    "You can export up to 10,000 rows on the free plan.",
]

def embed(text):
    return client.embeddings.create(
        model="text-embedding-3-small",
        input=text
    ).data[0].embedding

# La question d'un client
question = "I can't log in to my account"
q_vec = embed(question)
doc_vecs = [embed(d) for d in docs]

# Trouver l'article le plus proche par le sens
import numpy as np
scores = [np.dot(q_vec, d) for d in doc_vecs]
best = docs[int(np.argmax(scores))]
print("Best match:", best)

Cela renvoie l'article sur le mot de passe, même si le client n'a jamais dit « mot de passe ». Le problème est entièrement résolu, sans chatbot, sans flux conversationnel, et avec bien moins de risque que l'IA invente de mauvaises réponses.

Pour une explication claire et gratuite du fonctionnement des embeddings et de la recherche sémantique, voir le guide des embeddings d'OpenAI.

Quand vous avez réellement besoin du chatbot

Penser problème d'abord ne veut pas dire « ne jamais construire d'IA ». Cela veut dire construire la bonne chose.

Si votre analyse montrait que la plupart des questions étaient *uniques*, impliquaient des échanges (« mon export a échoué, voici mon erreur, que faire ? »), et exigeaient de raisonner sur plusieurs documents, alors un assistant IA conversationnel mérite sa place.

Le test est simple. Demandez : le problème exige-t-il une conversation, ou juste une réponse ?

• Juste une réponse : recherche, résumé, un seul appel à l'IA.
• Une conversation : un chatbot ou un assistant.

La plupart des équipes présupposent « conversation » par défaut. La plupart des problèmes n'ont besoin que d'une « réponse ».

Une checklist de décision rapide

Passez toute idée d'IA par ces questions avant de construire :

1. Puis-je énoncer le problème sans nommer une technologie ? Si vous ne pouvez le décrire que comme « un truc d'IA », vous ne l'avez pas encore compris.
2. Qui ressent la douleur, et à quelle fréquence ? Une douleur rare justifie rarement un projet.
3. Quelle est la solution la plus bête qui pourrait marcher ? Essayez-la d'abord. Un tableur, une meilleure barre de recherche, un modèle de prompt enregistré.
4. À quoi ressemble le succès sous forme de chiffre ? Si vous ne pouvez pas le mesurer, vous ne pouvez pas l'améliorer.
5. Que se passe-t-il quand l'IA se trompe ? Une mauvaise réponse dans une FAQ est agaçante. Une mauvaise réponse médicale ou juridique est dangereuse. Plus les enjeux sont élevés, plus les conceptions doivent être simples et contrôlées.

Dimensionner la solution au problème

Une fois le problème identifié, adaptez l'outil. En faire trop coûte de l'argent et ajoute des points de défaillance. En faire trop peu laisse la douleur intacte. Voici une échelle approximative, du plus simple au plus complexe :

Niveau 0 : pas d'IA

Une page FAQ mieux organisée. Un filtre de recherche. Un modèle. Parfois le vrai problème est que l'information est cachée, pas qu'elle est absente. Vérifiez toujours cela d'abord.

Niveau 1 : un seul appel à l'IA

Un prompt, une réponse. « Résume ce document. » « Classe cet e-mail comme urgent ou non. » Pas de mémoire, pas de conversation. Bon marché, prévisible, facile à tester.

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Classify the support email as 'billing', 'technical', or 'other'. Reply with one word."},
        {"role": "user", "content": "My card was charged twice this month."}
    ]
)
print(response.choices[0].message.content)  # billing

Ce seul extrait pourrait router automatiquement chaque e-mail entrant vers la bonne équipe. Cela seul pourrait résoudre le vrai goulot d'étranglement de l'équipe support.

Niveau 2 : l'IA plus vos propres données

C'est l'exemple de recherche sémantique vu plus haut, souvent appelé RAGRAGMéthode qui permet à un modèle d'IA de répondre à partir de vos propres documents, en récupérant les passages pertinents avant de générer une réponse.Voir la définition complète → (Retrieval-Augmented Generation : l'IA va chercher l'information pertinente dans vos documents, puis répond en s'appuyant dessus). Utile quand les réponses doivent venir de *votre* contenu, pas des connaissances générales du modèle.

Niveau 3 : un assistant conversationnel

Chat multi-tours, mémoire de la conversation, peut-être la capacité d'agir. Le plus puissant et le plus coûteux à construire et à maintenir. Réservez-le aux problèmes qui exigent un dialogue.

La leçon : partez du niveau le plus bas qui résout le problème. Vous pourrez toujours monter. Descendre (arracher un chatbot surdimensionné) est douloureux et public.

Pourquoi cela vous sauve

Cadrer d'abord donne l'impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → d'être lent. C'est en réalité le chemin le plus rapide. L'équipe support a perdu trois mois à construire la mauvaise chose. Le bon cadrage les aurait orientés vers un champ de recherche qu'ils auraient pu livrer en deux semaines.

Chaque heure passée sur les quatre questions de cadrage (la tâche, qui, la métrique, le correctif le plus simple) vous économise des semaines passées à construire quelque chose que personne n'a demandé.

Points clés

• Partez du problème, jamais de l'outil. Si vous ne pouvez décrire votre idée que par « ajoutons de l'IA », vous ne l'avez pas encore cadrée. Énoncez la douleur, qui la ressent, et à quelle fréquence.
• Définissez une métrique de succès mesurable avant de construire. « Réduire de 40 % les tickets “comment faire pour” » vaut mieux que « améliorer le support » parce que vous pouvez réellement le vérifier.
• Essayez toujours la solution la plus bête d'abord. Une meilleure recherche, un prompt enregistré, une règle de routage. Beaucoup de « projets IA » se résolvent au niveau 0 ou 1, sans le moindre chatbot.
• Adaptez la complexité au problème. Besoin d'une réponse ? Une recherche ou un seul appel à l'IA. Besoin d'une conversation ? Alors, et seulement alors, construisez un assistant.
• Demandez ce qui se passe quand l'IA se trompe. Des enjeux élevés exigent des conceptions plus simples et plus contrôlées, pas plus tapageuses.