Coup de gueule mesuré sur une exigence absurde qu'on impose aux machines, et jamais à nous-mêmes.
Il y a une phrase qui revient à chaque comité, à chaque atelier, à chaque réunion de cadrage. Quelqu'un finit toujours par la dire, sur un ton qui clôt le débat : « Oui, mais le modèle s'est trompé. »
Et là, tout s'arrête. Comme si une seule erreur suffisait à condamner l'outil. Comme si « se tromper » était une faute disqualifiante. Comme si nous, humains, ne nous trompions jamais.
Ce billet, c'est un coup de gueule. Un coup de gueule mesuré, mais un coup de gueule quand même.
On exige des machines ce qu'on n'exige de personne
Demandez à un développeur senior d'estimer la complexité d'un module legacy en cinq minutes, sans contexte. Il vous donnera une réponse plausible, parfois fausse. Personne ne propose de le licencier pour autant.
Demandez à un analyste de résumer un rapport de quarante pages en trois lignes. Il oubliera quelque chose. C'est mécanique : résumer, c'est choisir, et choisir, c'est laisser de côté.
Demandez à n'importe qui une réponse immédiate sur un sujet complexe, et vous obtiendrez une approximation. C'est le prix de l'immédiateté. Nous le savons, nous l'acceptons, nous avons construit des processus entiers — la relecture, la revue, le double regard — précisément parce que personne n'est fiable à 100 % du premier coup.
Et puis arrive un LLM. On lui demande la même chose. Il se trompe une fois sur vingt. Et là, soudain, l'erreur devient inacceptable.
Deux poids, deux mesures.
Le vrai problème n'est pas l'erreur. C'est l'absence de filet.
Soyons clairs : nous ne plaidons pas pour accepter n'importe quoi. Un système qui se trompe sans contrôle, sans validation, sans garde-fou, est un système dangereux. Sur ce point, aucune indulgence.
Mais le problème, dans ce cas, ce n'est pas que le modèle se soit trompé. C'est qu'on l'ait laissé se tromper sans filet.
Quand un humain peut commettre une erreur coûteuse, on ne lui demande pas d'être infaillible. On met en place une revue, une validation à quatre yeux, un seuil au-delà duquel un second avis est obligatoire. On conçoit le processus autour de la faillibilité.
Pourquoi diable ferait-on autrement avec une IA ?
Traiter chaque réponse d'un modèle comme un appel à un collègue compétent mais faillible — qu'on relit, qu'on recoupe, qu'on encadre sur les décisions sensibles — voilà la posture saine. Pas « le modèle doit être parfait ». Mais « le système doit être conçu pour qu'une erreur du modèle n'ait jamais de conséquence irréversible ».
L'exigence de perfection est une fuite
Et puis il y a le non-dit. Réclamer la perfection, c'est souvent une façon élégante de ne rien faire.
Tant que l'IA n'est pas parfaite — et elle ne le sera jamais, pas plus que nous — on a une excuse en or pour reporter, pour attendre « la prochaine version », pour rester les bras croisés pendant que d'autres avancent. L'exigence d'infaillibilité n'est pas de la rigueur. C'est, le plus souvent, de la procrastination déguisée en prudence.
Pendant ce temps, les équipes qui acceptent l'imperfection — qui la bordent au lieu de la fuir — construisent des systèmes qui apportent de la valeur dès aujourd'hui. Imparfaits, oui. Utiles, surtout.
Ce que nous voudrions entendre en réunion, pour changer
À la place de « Oui, mais le modèle s'est trompé », nous aimerions entendre :
« D'accord, il peut se tromper. Sur quels cas ? À quelle fréquence ? Quelles conséquences ? Et qu'est-ce qu'on met en place pour que ça ne fasse jamais mal ? »
Ces quatre questions valent mille fois mieux que le réflexe de rejet. Parce qu'elles transforment une fin de non-recevoir en problème d'ingénierie. Et les problèmes d'ingénierie, eux, ont des solutions.
C'est tout le métier : ne pas attendre la machine parfaite, mais construire le système fiable autour de la machine imparfaite. La perfection n'est pas le ticket d'entrée. La maîtrise, si.
Voilà. Coup de gueule terminé. On peut reprendre la réunion. 😌
-> Un billet d'humeur signé Olympp. Les opinions y sont assumées ; le débat est ouvert.
