Problème et valeur : où l'IA apporte un levier

Pourquoi ce chapitre est le plus utile

La majorité des projets IAintelligence artificielleIAEnsemble des techniques permettant à un programme d'accomplir une tâche qui demanderait de l'intelligence humaine. Le terme couvre aussi bien les systèmes à règles écrites que ceux qui apprennent de données.Voir dans le glossaire qui échouent ne meurent pas d'un mauvais modèle ni d'un manque de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire : ils meurent d'un mauvais problème. L'équipe construit une réponse technique impressionnante à une question que personne ne posait, ou automatise une tâche où l'erreur occasionnelle coûte plus cher que le temps économisé. Ce chapitre ne parle pas encore d'architecture, de RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire ni d'agentsagentIASystème qui enchaîne des appels d'outils de façon autonome pour atteindre un objectif : il planifie, agit, observe, recommence. Sa fiabilité décroît exponentiellement avec le nombre d'étapes.Voir dans le glossaire : il porte sur le tri qui doit avoir lieu avant, et qui conditionne tout le reste de cette formation.

Cadrer un produit IA correctement, c'est répondre à trois questions dans l'ordre : quelle tâche l'utilisateur essaie-t-il réellement d'accomplir (le job-to-be-done), cette tâche tolère-t-elle la nature probabiliste d'un système génératif, et existe-t-il déjà une alternative déterministe qui ferait aussi bien, plus simplement. Sauter cette étape ne fait pas gagner de temps : elle en fait perdre, six mois plus tard, quand le POC impressionne en démo et s'effondre en production faute d'avoir été construit sur la bonne tâche.

Un produit IA ne se cadre pas par la technologie disponible mais par la tâche et sa tolérance à l'erreur. Si vous partez de « qu'est-ce qu'on pourrait faire avec un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire », vous construisez une solution qui cherche un problème.

Le job-to-be-done : reformuler avant de coder

Le cadre du job-to-be-done (JTBD), popularisé dans le développement produit bien avant l'IA générative, part d'un principe simple : un utilisateur n'achète pas une fonctionnalité, il « embauche » un produit pour accomplir une tâche dans un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire donné. Appliqué à un projet IA, ce cadre oblige à sortir du vocabulaire technique — « on veut un chatbot », « on veut du RAG sur notre documentation » — pour formuler la tâche réelle en une phrase du type : quand [situation], l'utilisateur veut [action], afin que [résultat attendu].

Cette reformulation change souvent la nature du projet. Une équipe support qui demande « un chatbot pour répondre aux clients » formule en réalité plusieurs jobs distincts : trouver rapidement la procédure interne correspondant à un ticket, rédiger une réponse cohérente avec le ton de la marque, ou détecter les tickets à escalader avant qu'ils ne dégénèrent. Ce sont trois produits différents, avec des exigences de fiabilité différentes, et parfois une seule des trois mérite un système génératif.

La reformulation JTBD sert aussi de test de sincérité vis-à-vis du sponsor du projet. Si personne ne parvient à formuler la phrase avec un résultat mesurable, c'est le signe que le projet part d'une opportunité technologique plutôt que d'un besoin identifié — et le risque d'échec grimpe en conséquence.

Faites reformuler la demande initiale par trois personnes différentes de l'équipe métier, séparément. Si les trois formulations JTBD diffèrent significativement, le problème n'est pas encore assez cadré pour lancer un POC.

Cartographier la valeur : la matrice volume × tolérance à l'erreur

Une fois le job identifié, il faut évaluer s'il constitue un terrain favorable pour un système probabiliste. Deux axes suffisent dans la grande majorité des cas : le volume ou la répétition de la tâche (est-elle exécutée une fois par mois ou mille fois par jour ?) et la tolérance à l'erreur du contexte (une réponse fausse coûte-t-elle une relecture de trente secondes, ou déclenche-t-elle un remboursement, un litige, un risque réglementaire ?).

<text x="465" y="85" text-anchor="middle" fill="#7dffb0" font-weight="700">Levier fort</text>
<text x="465" y="103" text-anchor="middle" fill="#c4cbdb">tri, résumé, brouillon, recherche</text>

<text x="215" y="243" text-anchor="middle" fill="#ff9d9d" font-weight="700">Non-problème</text>
<text x="215" y="261" text-anchor="middle" fill="#c4cbdb">rester déterministe / règles</text>

<text x="465" y="243" text-anchor="middle" fill="#ffd27d" font-weight="700">Sous supervision</text>
<text x="465" y="261" text-anchor="middle" fill="#c4cbdb">humain dans la boucle obligatoire</text>

Le quadrant en haut à droite — tâche fréquente, erreur tolérable — est le terrain naturel des LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire : rédaction de premiers jets, résumé de documents longs, tri et catégorisation de contenu entrant, recherche dans une base documentaire. Une erreur y coûte une relecture, pas un incident. Le quadrant en bas à gauche — tâche rare, erreur coûteuse — est en général mieux traité par une règle métier explicite, un formulaire ou une validation manuelle : construire un système probabiliste pour un cas qui survient dix fois par an et où l'erreur est inacceptable revient à sur-outiller.

Les deux quadrants restants demandent plus de nuance. Une tâche fréquente à faible tolérance à l'erreur (validation de virements, diagnostic médical préliminaire, décision de crédit) peut légitimement embarquer de l'IA, mais uniquement avec un humain dans la boucleHuman-in-the-loopIABoucle où un opérateur humain valide, corrige ou arbitre les décisions du système IA avant une action irréversible.Voir dans le glossaire et des garde-fous — jamais en autonomie complète. Une tâche rare à forte tolérance à l'erreur mérite rarement l'investissement d'un projet IA dédié : le gain est réel mais trop marginal pour justifier l'effort d'ingénierie, de gouvernance des données et de maintenance qu'un système en production impose.

Les non-problèmes : quand l'IA est la mauvaise réponse

Un non-problème n'est pas un problème mal formulé : c'est un problème réel, mais pour lequel l'IA générative n'est pas l'outil adapté, parce qu'une autre approche fait mieux à moindre coût et moindre risque. Les identifier tôt évite des mois de développement sur une fondation bancale.

• Le calcul exact. Un LLM ne calcule pas, il prédit la suite la plus probable d'une séquence de tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire. Pour un calcul de facturation, une conversion d'unités ou une vérification d'IBAN, une fonction déterministe est plus rapide, moins chère et infiniment plus fiable qu'un modèle génératif, même appelé en agent avec un outil de calcul en renfort inutile.
• La règle métier déjà exhaustive. Si un arbre de décision à cinq branches couvre 100 % des cas rencontrés depuis trois ans, remplacer ce moteur de règles par un LLM ajoute de la latence, du coût d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire et une source d'erreur non déterministe, pour un gain de flexibilité que personne n'a demandé.
• La recherche exacte dans un jeu de données structuré. Chercher « la commande n°48213 » relève d'une requête SQL, pas d'une recherche sémantique. Faire passer cette requête par un LLM, c'est introduire un risque d'hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire là où une clé primaire suffisait.
• La décision à haut risquehaut risqueConformitéCatégorie de l'AI Act regroupant les usages soumis à conditions strictes : recrutement, crédit, éducation, infrastructures critiques. Elle impose documentation, examen des biais et contrôle humain effectif.Voir dans le glossaire sans réversibilité. Une décision d'éligibilité, un diagnostic engageant, un rejet de dossier définitif : quand l'erreur est difficilement réversible et que la responsabilité légale est engagée, l'IA générative peut assister l'analyse mais ne doit jamais trancher seule.
• Le problème que personne n'a validé. Le cas le plus fréquent en pratique : un besoin supposé, jamais vérifié auprès des utilisateurs réels, où l'équipe projette une douleur qui n'existe pas à l'usage. Le meilleur modèle du monde ne rendra pas utile un produit que personne ne voulait.

Si la justification du projet commence par « on a un LLM disponible, qu'est-ce qu'on pourrait en faire », le cadrage part à l'envers. Repartez du job-to-be-done, pas de la technologie.

Une équipe interne voulait un assistant conversationnel pour consulter le solde de congés des salariés. Le système existant affichait déjà ce solde en un clic dans le SIRH. Le vrai job-to-be-done, révélé après trois entretiens utilisateurs, était de simuler l'impact d'une demande de congé sur le solde restant avant de la poser — un calcul déterministe, pas une conversation. Le projet IA a été abandonné au profit d'un simulateur classique livré en deux semaines.

Estimer la valeur avant le POC

Une fois le quadrant identifié, il reste à chiffrer l'ordre de grandeur du gain avant d'investir dans un prototype. Trois questions suffisent à produire une estimation grossière mais suffisante pour prioriser :

Ce chiffrage grossier suffit à comparer plusieurs candidats projets entre eux avant de lancer le moindre développement. Un projet à fort volume et faible coût d'erreur (le support de premier niveau, par exemple) devrait presque toujours passer avant un projet à faible volume et fort coût d'erreur, même si ce dernier semble plus impressionnant en démo.

À ce stade, l'objectif n'est pas de produire un ROI au centime près mais de classer les candidats projets entre « levier probable », « à valider » et « non-problème ». Le chiffrage précis vient après le POC, sur des données réelles d'usage.

Checklist de cadrage

Avant d'ouvrir un ticket de développement, vérifiez que chaque point suivant a une réponse écrite, partagée avec le sponsor métier :

• Le job-to-be-done est formulé en une phrase, sans vocabulaire technique
• Trois personnes différentes de l'équipe métier valident la même formulation
• Le volume hebdomadaire ou mensuel de la tâche est chiffré, pas estimé à l'instinct
• Le coût d'une erreur non détectée est explicité et jugé tolérable, ou une supervision humaine est prévue dès la conception
• Aucune alternative déterministe (règle, formulaire, requête) ne couvre déjà 80 % des cas
• Un premier utilisateur réel a confirmé la douleur, indépendamment de l'équipe projet
• Un indicateur de succès mesurable est défini avant le POC, pas après

Si l'un de ces points reste sans réponse, ce n'est pas un motif pour renoncer au projet, mais un signal qu'il faut poursuivre le cadrage — au tableau blanc, pas dans le code.

Pièges fréquents

Le premier piège est la confusion entre impressionner et résoudre : une démo de chatbot capable de répondre à des questions générales sur l'entreprise séduit en réunion, mais ne répond à aucun job précis si personne ne sait dire quelle tâche concrète elle raccourcit. Le deuxième piège est l'extrapolation du volume : une équipe surestime presque toujours la fréquence réelle d'une tâche rare mais mémorable (l'incident client difficile) et sous-estime le volume d'une tâche routinière mais invisible (le tri quotidien des pièces jointes). Le troisième piège est de traiter la tolérance à l'erreur comme binaire : elle varie selon le sous-cas, et un même produit peut mélanger des requêtes à faible et à fort enjeu — d'où l'intérêt de router ces cas différemment plutôt que de les traiter avec un seul niveau de garde-fou.

Enfin, le piège le plus coûteux reste organisationnel : lancer le développement avant que le sponsor métier ait formellement validé le job-to-be-done et le niveau de risque accepté. Un POC techniquement réussi mais construit sur un job mal validé se heurte, en phase de déploiement, à un désaccord qu'il aurait fallu trancher avant la première ligne de code.

Ce qu'il faut retenir

Cadrer un produit IA commence par une reformulation en job-to-be-done, se poursuit par un positionnement dans la matrice volume × tolérance à l'erreur, et se conclut par un chiffrage grossier de la valeur récupérable. Ce travail de cadrage, qui ne nécessite ni modèle ni infrastructure, élimine la majorité des projets voués à l'échec avant qu'ils ne coûtent un euro de développement. Les chapitres suivants supposent ce filtre franchi : ils portent sur la construction du POC, son passage à l'échelle, et les architectures adaptées — mais aucun ne compense un problème mal choisi au départ.