Un projet d'IA ne meurt pas d'un mauvais modèle, il meurt d'un mauvais périmètre

J’ai vu suffisamment de projets d’intelligence artificielle s’arrêter pour reconnaître la forme que prend leur mort. Elle est presque toujours la même, et elle ne ressemble pas à ce qu’on imagine. Le modèle fonctionne. La démonstration a impressionné le comité de direction. Le prototype répond correctement dans 90 % des cas. Et pourtant, six mois plus tard, personne ne l’utilise, le budget est consommé, et l’organisation conclut que « l’IA n’est pas encore mûre pour nous ». Ce diagnostic est presque toujours faux. Ce qui n’était pas mûr, c’est le périmètre.

Je précise ce que j’entends par périmètre, parce que le mot est usé. Il ne s’agit pas de la liste des fonctionnalités. Il s’agit de la réponse à quatre questions qui n’ont rien de technique et que la plupart des cadrages escamotent : qui est responsable du résultat, comment on le mesure, quel taux d’erreur on accepte, et ce qui se passe quand la machine se trompe. Un projet qui n’a pas répondu à ces quatre questions par écrit n’est pas un projet, c’est une intention.

Les quatre tests, en un tableau

Test	Question posée	Ce qui invalide le cas d’usage
Propriétaire	Qui répondra, dans 90 jours, de l’usage réel ?	Un chef de projet responsable de la livraison, pas du résultat
Mesure	Quelle est la valeur de départ, aujourd’hui ?	Aucune mesure avant déploiement, ou une mesure d’opinion
Seuil d’erreur	À partir de quel taux d’échec est-ce non rentable ?	Seuil non chiffré, ou découvert au premier incident
Recours	Que fait l’utilisateur quand la réponse est fausse ?	Aucune correction, aucune source, aucune escalade

Un cas d’usage qui échoue à l’un de ces quatre tests n’est pas prêt, quelle que soit la qualité de la démonstration. Les sections suivantes détaillent chacun d’eux.

Le propriétaire du résultat, pas du projet

La première question est celle qu’on croit avoir résolue en nommant un chef de projet. Ce n’est pas la même chose. Un chef de projet est responsable de la livraison ; il a réussi quand la fonctionnalité est en ligne. Le propriétaire du résultat est responsable de l’usage ; il n’a réussi que si quelqu’un s’en sert et que le chiffre qu’on suivait a bougé.

L’absence de cette seconde personne est le prédicteur d’échec le plus fiable que je connaisse. Elle produit une situation caractéristique : la fonctionnalité est livrée, l’équipe technique considère le mandat rempli, l’équipe métier n’a jamais été consultée sur son intégration dans le flux de travail réel, et l’outil reste dans un onglet que personne n’ouvre. Personne n’a menti, personne n’a mal travaillé, et pourtant le résultat est nul.

Concrètement, je refuse désormais d’engager un cadrage sans qu’une personne nommée — pas une direction, une personne — accepte par écrit d’être celle à qui l’on demandera, dans 90 jours, si le chiffre a bougé.

La mesure doit exister avant, pas après

La deuxième condition semble évidente et elle est presque toujours violée. Pour savoir si une fonctionnalité d’IA a produit de la valeur, il faut connaître la valeur de départ. Combien de tickets de support par semaine, avant. Quel délai moyen de traitement, avant. Quel taux de conversion sur le moteur de recherche interne, avant.

Cette mesure de référence coûte peu à établir et devient impossible à reconstituer une fois le déploiement effectué. C’est le premier des cinq refus que je documente dans L’IA qui ne sert à rien : un projet sans point de départ mesuré ne pourra jamais prouver qu’il a produit quelque chose. Un projet qui démarre sans elle se condamne à une discussion invérifiable : l’équipe technique affirmera que ça marche, l’équipe métier aura l’impression que rien n’a changé, et aucune des deux ne pourra le prouver. La conversation se réglera alors sur des impressions et sur des rapports de force, ce qui est exactement la manière dont un budget se fait couper.

Il faut ajouter une exigence de qualité sur cette mesure : elle doit porter sur un comportement, pas sur une opinion. Le nombre de fois où la suggestion a été acceptée est une mesure. Le taux de satisfaction déclaré dans un sondage interne n’en est pas une — ou plus exactement, c’en est une trop tardive et trop bruitée pour piloter quoi que ce soit.

Un modèle qui se trompe dix fois sur cent est excellent ou inacceptable selon ce que coûte une erreur. Tant que ce coût n’est pas chiffré, la performance du modèle ne veut rien dire.

Le seuil d’erreur acceptable, accepté par écrit

Un système probabiliste se trompe. Ce n’est pas un défaut à corriger, c’est une propriété à gérer. La question opérationnelle n’est donc jamais « comment atteindre cent pour cent », mais « à partir de quel taux d’erreur cette fonctionnalité cesse-t-elle d’être rentable ».

Cette question a des réponses radicalement différentes selon le cas. Une suggestion de produit erronée coûte un clic à l’utilisateur ; un taux d’erreur de 20 % y est parfaitement supportable si les 80 % restants augmentent le panier moyen. Une réponse fausse sur un délai de livraison coûte un ticket de support et une érosion de confiance ; le seuil tolérable descend d’un ordre de grandeur. Une erreur sur une écriture comptable ou sur un calcul de taxe coûte un litige ; le seuil tombe à zéro, ce qui signifie qu’il faut soit une validation humaine systématique, soit renoncer.

Ce que j’exige en cadrage, ce n’est pas d’atteindre un chiffre particulier. C’est que le chiffre soit écrit et signé avant le déploiement. Une organisation qui découvre le seuil au moment du premier incident le fixera sous le coup de l’émotion, et il sera presque toujours fixé à zéro, ce qui tue la fonctionnalité.

Le recours, quand la machine se trompe

La quatrième condition est celle que les démonstrations occultent systématiquement, parce qu’une démonstration montre le chemin heureux. En production, la question qui détermine l’adoption est l’inverse : que fait l’utilisateur quand la réponse est fausse.

S’il n’a aucun recours — pas de bouton pour corriger, pas d’accès à un humain, pas de moyen de comprendre d’où sort la réponse — il apprendra en 3 occurrences à ne plus faire confiance au système, et il le contournera définitivement. La confiance dans un outil probabiliste ne se construit pas sur son taux de réussite ; elle se construit sur la prévisibilité de son échec. Un système qui se trompe visiblement, qui l’admet, et qui offre une sortie, est utilisé bien plus longtemps qu’un système plus performant mais opaque.

Concrètement, cela veut dire prévoir dès le cadrage : un moyen de signaler une erreur en un clic, un accès direct à la source de l’information proposée, et une escalade humaine dont le délai est annoncé. Ce sont des éléments d’interface, pas de modèle, et ils pèsent davantage sur l’adoption que le choix du fournisseur.

Faut-il commencer par un cas interne ou par une fonctionnalité publique ?

Ces quatre conditions ont une conséquence pratique que je veux énoncer clairement, parce qu’elle heurte souvent la première intention du client. Elles sont beaucoup plus faciles à satisfaire sur un cas d’usage étroit, interne, adressé à un utilisateur identifiable, que sur une fonctionnalité publique adressée à tout le trafic.

Un outil interne a un propriétaire évident, une mesure observable, un utilisateur qu’on peut interroger directement, et un coût d’erreur borné. On sait en 3 semaines s’il sert ou s’il a été contourné. Une fonctionnalité publique dilue chacun de ces signaux : le propriétaire est diffus, la mesure est noyée dans la variance du trafic, l’utilisateur est anonyme, et le diagnostic d’échec prend un trimestre.

Je recommande donc systématiquement de commencer par l’interne — non par prudence, mais parce que c’est le terrain sur lequel on apprend le plus vite. La visibilité externe vient ensuite, une fois qu’on sait mesurer. J’ai décrit ailleurs les chantiers qui, en pratique, remboursent le plus rapidement cet apprentissage¹.

Comment rédiger un cahier des charges d’IA en une page

La conclusion tient en une inversion. On commande habituellement un projet d’IA en décrivant ce que le système devra faire. Je propose de le commander en décrivant ce qu’on saura mesurer, qui en répondra, ce qu’on accepte de rater, et ce qu’on offrira à l’utilisateur quand ça ratera.

Ce cahier des charges là tient sur une page, il ne contient aucun terme technique, et il élimine avant tout investissement la majorité des cas d’usage qui auraient échoué. Ce n’est pas une méthode brillante ; c’est simplement l’endroit où se joue réellement le résultat. Le choix du modèle, lui, est devenu l’une des décisions les moins structurantes du projet — et c’est pourtant celle sur laquelle se concentre presque toute la conversation.

---

Footnotes

1. Sur les chantiers d’IA qui remboursent leur investissement dans un horizon court, et la manière de les séquencer, voir Trois chantiers d’IA mid-market qui paient leur retour sur investissement en 90 jours. Sur le cas inverse — les déploiements qui ne produisent rien — voir L’IA qui ne sert à rien. ↩