Le problème de l'orange

Il y a dix ans, un investisseur m'a dit que j'avais un fouillis dans la tête. Il avait raison, et il m'a fallu dix ans et une caisse d'oranges pour voir exactement quel genre de fouillis c'était.

Une échelle là où il n'y en avait pas

Les oranges ne sont pas les miennes — j'ai entendu ce cas lors d'un atelier, raconté par quelqu'un qui l'avait construit chez Microsoft. Chez un producteur de fruits, des gens se tenaient au-dessus d'une chaîne d'emballage et tranchaient pour chaque fruit : les vertes partent à Seattle, les orange restent en Floride. Deux états. C'était toute la résolution du système, parce que c'est la résolution d'un œil humain qui regarde des oranges depuis six heures du matin.

Ils ont installé un modèle de vision sur la chaîne. Il lisait la surface du fruit et donnait un chiffre : le nombre de jours avant que le fruit ne se gâte. Pas deux paniers — une échelle. Et une échelle est un objet d'une tout autre nature qu'un panier. On peut intégrer une échelle dans un calcul logistique. On peut router dessus, tarifer dessus, décider dessus.

Ce qui m'a frappé, ce n'est pas le modèle. C'est que personne dans cette entreprise ne demandait de l'IA. Ils avaient un problème de pertes à l'expédition, et la perte venait d'une mesure qui n'existait pas. La technologie n'a compté que parce qu'elle a produit le chiffre manquant.

Le KPI qui ne fonctionne pas

Je me suis heurté au même mur, du côté opposé, à l'échelle d'un État.

Une partie de mon travail en tant que CIO — Kyrgyz Single Window consiste à diriger l'IA pour les systèmes douaniers nationaux. À un moment, nous avons dû répondre à une question qui semblait raisonnable : quels sont les KPI de nos services d'IA ?

Chaque réponse intuitive est fausse, et fausse d'une manière instructive. Le nombre de systèmes d'IA déployés — on obtient des systèmes que personne n'utilise. La part des processus touchés par l'IA — on obtient de l'IA insérée dans des processus qui fonctionnaient déjà bien. Le taux d'adoption — on obtient du théâtre d'adoption. Toutes ces mesures évaluent la diffusion de la technologie, et la diffusion de la technologie ne profite à personne.

La question utile s'est révélée bien plus petite et bien plus difficile : quelle tâche précise, nommée, coûteuse est devenue moins chère ?

J'ai trouvé ma réponse dans une conversation, pas dans un document de planification. Un fonctionnaire du ministère de l'Économie a décrit une tâche qui dévorait des heures de sa semaine et des heures de celles de ses collègues. Il ne présentait pas un projet — il se plaignait. Écouter cette seule plainte a produit ai.trade.kg — un outil fonctionnel qui a supprimé cette tâche précise.

Voilà un KPI défendable : des heures, sur un processus nommé, avant et après. C'est aussi, non par hasard, le seul type de projet d'IA que j'ai vu survivre au contact d'une organisation.

Ce qui en découle quand on construit pour un seul problème

Voici la partie que je n'attendais pas.

Quand on construit de l'IA pour un problème nommé au sein d'une organisation régulée — un système douanier, un cabinet d'avocats, une clinique — les contraintes cessent d'être des obstacles et deviennent l'architecture. Les données ne peuvent pas quitter le périmètre, donc le modèle tourne sur leur matériel. La réponse doit être vérifiable, donc chaque affirmation cite le fragment de document dont elle est issue. Personne n'agira sur la sortie d'une machine sans médiation, donc un opérateur valide tout ce qui dépasse un seuil, et ce seuil appartient au client, pas à moi.

Construisez ainsi pendant un moment et regardez ce que le système a accumulé de lui-même : un enregistrement de chaque décision et de la règle qui l'a produite, un journal de qui a validé quoi et quand, les sources exactes derrière chaque réponse, figées de sorte qu'elles survivent à la suppression du document original.

C'est une piste d'audit. Personne ne l'a demandée. C'est un sous-produit du fait que le système fait son travail, parce que le système ne peut pas faire son travail sans laisser de trace.

Pendant ce temps, tout un marché se forme au-dessus de cette couche : registres d'IA, plans de contrôle, certifications d'assurance, dossiers de preuves. De vrais produits résolvant un vrai problème — des entreprises déployant des agents que personne ne suit. Mais regardez ce qu'ils doivent faire. Ils s'installent au-dessus de systèmes qui n'ont jamais été conçus pour être responsables, et ils compilent la responsabilité après coup, à la main, depuis l'extérieur.

J'ai commencé à appeler l'alternative garantie par construction, par opposition à la garantie par attestation. Pas une couche de gouvernance ajoutée à un produit. Un produit dont l'architecture ne peut pas fonctionner sans produire la preuve. Cette distinction compte surtout là où elle est la plus difficile à simuler : une organisation de trois cents personnes n'engagera jamais un organisme de certification, mais elle acceptera volontiers une piste d'audit qui s'écrit d'elle-même.

La même erreur, chez moi

Puis j'ai regardé mon propre site.

Huit éléments dans la navigation. Une page d'accueil qui disait que j'explorais comment les LLM et les interfaces s'articulent. Une plateforme d'IA souveraine pour cabinets d'avocats dans la même grille qu'une marketplace de matériel d'occasion et un roguelite en pixel art. Une page de services tarifée à l'heure, qui indique à tout acheteur sérieux qu'il a affaire à une paire de mains.

C'était le KPI du taux d'adoption, appliqué à une carrière. Beaucoup de surface, aucun problème nommé. Je me faisais à moi-même exactement ce que je dis à mes clients de ne pas faire.

Il y a une phrase à laquelle je reviens sans cesse, et elle ne vient pas de la technologie — elle vient d'un vieux principe publicitaire : il faut rendre chaque détail parfait, et il faut limiter le nombre de détails. La seconde clause est la difficile. Ajouter est agréable. C'est retrancher qui produit la clarté.

Et la clarté est tout le mécanisme commercial. Un esprit confus dit non. Pas « peut-être » — non. Si la personne en face de vous ne peut pas répéter ce que vous faites, elle n'achètera pas, quel qu'en soit le prix et aussi bon que ce soit.

L'offre, formulée une fois

Donc : une seule phrase, et tout le reste à son service.

Je construis des systèmes d'IA pour des organisations dont les données ne peuvent pas quitter le périmètre.

Cabinets d'avocats, cliniques, autorités douanières, family offices — des équipes qui ne peuvent pas coller leur travail dans un chatbot cloud. La mission commence par trente minutes sur ce qui fait réellement perdre du temps à votre équipe chaque semaine, et l'un des résultats légitimes de cette conversation est ne construisez pas cela pour l'instant, par écrit, avec les raisons.

En dessous, trois couches que je sépare délibérément, parce qu'elles répondent à des questions différentes :

• Ce que je vends, c'est une solution. Pas une technologie, pas un programme de transformation. Un problème nommé, écarté.
• La façon dont c'est conditionné, c'est la commodité. Des systèmes prêts tournant dans votre propre contour, plutôt que d'embaucher une équipe pour les construire.
• Pourquoi c'est moi, c'est l'expérience — ce que ça fait de travailler ainsi : pas de jargon, pas de théâtre, un prototype fonctionnel plutôt qu'une présentation, et une réponse franche quand la réponse est non.

Les oranges, le ministère et ma propre page d'accueil sont la même leçon à trois échelles. L'IA n'est pas quelque chose qu'on adopte. C'est quelque chose qu'on pointe vers un seul problème coûteux, avec assez de précision pour pouvoir dire ensuite si ça a marché.

Tout le reste n'est que de la surface.