Quand l’IA
commence à décider

Shail Khiyara

Avant le début d’un concert, la salle n’est que le bruit de quarante instruments. Personne ne résout cela en accordant tous les instruments en même temps. Un hautbois joue une seule note, le la, et le reste de l’orchestre s’y accorde. Cette note n’est pas choisie parce qu’elle est la plus forte ou la plus fausse. Elle est choisie parce que c’est autour d’elle que toute la salle doit s’organiser.

La fragmentation ne se situe pas dans les objectifs de l’entreprise. La plupart des opérateurs savent exactement ce qu’ils cherchent à résoudre : protéger la marge, tenir les niveaux de service, gérer le fonds de roulement. La fragmentation se trouve dans les données qu’il faudrait réunir pour réellement prendre la décision qui sous-tend cet objectif. Ce sont deux diagnostics différents, et partir du mauvais est précisément la manière dont les entreprises finissent par chercher à passer l’IA à l’échelle au lieu de passer une décision à l’échelle.

Notre séquence commence par l’objectif, pas par les données. Nous commençons par préciser l’économie de la décision : ce qu’elle vaut, ce que coûte une mauvaise décision, à quoi ressemblent réellement les paramètres économiques unitaires qui la sous-tendent. Ce n’est qu’une fois cela compris que nous allons chercher les données qui l’alimentent, où qu’elles se trouvent. Si vous partez des données, vous héritez de la structure en silos déjà existante. Si vous partez de l’économie de la décision, le besoin en données est défini par le problème, et non par l’organigramme.

C’est aussi ce qui l’empêche de devenir un nouveau silo. Il ne s’agit ni d’une base de données partagée ni d’un schéma commun. À chaque mission, nous reconstruisons d’abord l’économie de la décision qui se présente à nous avant même de toucher aux données, et c’est cette discipline qui se transmet. Deux décisions prises dans deux parties différentes de l’entreprise pourront puiser dans des systèmes entièrement différents.

C’est une approche du problème par la pensée systémique avant d’être une question d’architecture. La deuxième décision n’a pas besoin d’un seul octet de ce qu’a utilisé la première. Elle a seulement besoin de la même discipline qui a permis de trouver la première note.

Shail Khiyara

Une voiture autonome vous rendra le contrôle dès qu’elle détecte une situation qu’elle ne peut pas totalement résoudre : une insertion, une zone de travaux, de la pluie sur un capteur. Personne n’appelle cela un échec de l’autonomie. C’est le système qui fonctionne comme il a été conçu. La confiance se construit kilomètre après kilomètre, sans incident ; elle n’est pas accordée dès le premier jour.

C’est assez proche de la situation actuelle de SWARM, et je préfère le dire clairement plutôt que l’enrober. Aujourd’hui, dans chaque déploiement en production, SWARM produit une recommandation. Un humain la met en œuvre. La validation humaine est universelle : ce n’est pas limité à un type de décision ou à un client. Lorsque je dis que nous sommes agentiques au sens où mon livre le décrit — percevoir, raisonner et agir — je parle de la direction dans laquelle nous allons.

Cette séquence est délibérée, et c’est aussi ce que veulent réellement la plupart des clients. Presque personne ne nous demande de lâcher le volant dès le premier jour. Ils veulent observer le modèle raisonner sur de vraies décisions, vérifier que sa logique tient face à ce qu’auraient fait leurs propres opérateurs, puis seulement discuter de ce à quoi pourrait ressembler une intégration plus profonde. Valider, déployer, puis intégrer directement dans leurs systèmes. Ce n’est pas une prudence que nous leur imposons. C’est la séquence que choisissent les clients, parce que faire confiance à une recommandation que l’on peut contrôler est très différent de faire confiance à une action que l’on ne peut pas reprendre.

Ce qui détermine si une catégorie de décisions est prête à passer d’une mise en œuvre humaine à une exécution par le système repose sur les trois mêmes éléments que nous observons dans tout système HITL : la fréquence à laquelle l’humain annule ou modifie notre recommandation, le coût nécessaire pour revenir sur une mauvaise décision si elle est effectivement appliquée, et la rapidité avec laquelle le résultat devient visible. Une décision de prix avec un retour le jour même gagne son autonomie plus vite qu’un calendrier de production qui engage une semaine de capital. Nous ne nous dirigeons pas vers un interrupteur unique d’autonomie pour SWARM. Nous nous dirigeons vers des dizaines d’interrupteurs, chacun n’étant augmenté qu’au rythme où une décision spécifique mérite cette autonomie.

Shail Khiyara

La corrélation ne coûte pas cher. N’importe quel fournisseur peut montrer un indicateur qui a évolué pendant que son logiciel était présent dans l’entreprise. La causalité coûte davantage, et son prix est une norme que vous êtes prêt à appliquer même lorsqu’elle produit une réponse qui ne vous plaît pas.

La mienne comporte trois éléments. Premièrement, le processus doit être suffisamment circonscrit pour que je puisse nommer tout ce qui pourrait plausiblement expliquer le résultat et écarter chaque facteur. Un indicateur à l’échelle de toute l’entreprise qui bouge pour une douzaine de raisons ne m’apprend rien. Un processus unique et spécifique, oui. Deuxièmement, j’ai besoin d’une base de référence mesurée avant le déploiement, sur ce processus précis, et non d’une impression générale selon laquelle « avant, c’était plus lent ». Troisièmement, le client doit être prêt à associer son nom à l’affirmation causale, pas seulement au résultat. Un résultat auquel personne ne veut associer son nom est une rumeur, pas une preuve.

Industrial Labs est le cas où les trois éléments se sont alignés. La situation initiale reposait sur un processus identifiable : une planification manuelle pilotée par tableur. Nous avons remplacé ce processus par SWARM ENGINE. Rien d’autre dans leurs opérations n’a changé au même moment : aucune migration d’ERP, aucune réorganisation, aucune nouvelle discipline de processus ajoutée en parallèle. Le délai de traitement s’est amélioré de 32 %. La répartition de la charge de travail des analystes est devenue 97 % plus équilibrée. Lorsque l’on me demande si cela vient de SWARM ou d’autre chose, j’ai une réponse, parce qu’il n’y avait presque rien d’autre qui pouvait l’expliquer.

Toutes les missions ne me donnent pas un test aussi propre, et je préfère le dire plutôt que d’arrondir la réalité. Une partie de notre travail porte sur de la coordination à une échelle où isoler une seule variable est réellement plus difficile. Ardent Mills utilise SWARM sur un vaste réseau meunier nord-américain pour planifier les flux de produits entre de nombreux sites et points de livraison clients. Un producteur en Amérique du Sud utilise SWARM pour planifier la main-d’œuvre et le transport de jusqu’à 15 000 travailleurs agricoles, transformant un cycle de planification mensuel en un processus rapide et reproductible. Ce sont des résultats réels, déployés et utiles. Je leur applique le même niveau d’exigence et, lorsque je ne peux pas isoler totalement un chiffre comme je peux le faire avec Industrial Labs, je le dis clairement plutôt que d’emprunter la confiance d’un cas plus propre pour masquer un cas plus complexe.

C’est cela, la discipline. Tous les résultats ne sont pas accompagnés d’un chiffre publié. Mais chaque chiffre que je rends public a passé le même test qu’Industrial Labs, et je préfère avoir moins de chiffres que je peux défendre que davantage de chiffres que je devrais ensuite retirer.

Shail Khiyara

Un ingénieur qui optimise une seule poutre isolément peut produire un calcul magnifique et un bâtiment qui ne tient pas debout, parce que la poutre n’a jamais constitué le système dans son ensemble. C’est le mode d’échec qui nous a posé le plus de difficultés : non pas une mauvaise action, mais une réponse techniquement correcte apportée au mauvais problème.

Nous avons eu un cas où le modèle a produit ce qui ressemblait à une allocation optimale. Des chiffres propres, de vrais gains d’efficacité, rien de faux dans les mathématiques. Mais cette allocation violait aussi un accord collectif qu’aucun membre de l’équipe n’avait encodé comme contrainte, parce qu’il ne figurait dans aucun jeu de données : il vivait dans un contrat et dans la mémoire institutionnelle de personnes qui l’avaient négocié des années auparavant. Un opérateur l’a détecté avant que cela n’aille plus loin. Mais c’est le schéma qui m’inquiète le plus : non pas un agent qui exécute une mauvaise action, puisque rien ne s’exécute sans humain aujourd’hui, mais une recommandation localement optimale et globalement erronée, convaincante en surface, aveugle à une contrainte qui n’avait jamais fait partie de son univers.

La deuxième version du même échec se situe en amont, pas en aval. Des données obsolètes ou mauvaises qui alimentent un modèle ne se signalent pas comme telles. Elles produisent une recommandation qui paraît exactement aussi propre qu’une recommandation correcte. Des données mauvaises à l’entrée ne ressemblent pas à de mauvaises données à la sortie. Elles ressemblent à de la confiance.

Ce que cela nous a forcés à changer, ce n’est pas le modèle. C’est l’endroit où nous concentrons notre effort d’ingénierie avant même que le modèle ne tourne. Nous traitons désormais la découverte des contraintes comme une étape explicite à part entière : nous nous asseyons avec les personnes qui détiennent les règles non écrites, les accords sociaux, les limites de conformité, les relations — pas seulement avec celles qui possèdent les données — avant d’autoriser un système à optimiser quoi que ce soit. La pensée systémique n’est pas une phase que l’on ajoute une fois que les mathématiques fonctionnent. La recommandation la plus dangereuse n’est pas celle qui est fausse. C’est celle qui est correcte et qui, malgré tout, ne devrait pas être appliquée.

Shail Khiyara

J’ai maintenant vu passer trois générations de cette promesse — RPA, automatisation intelligente, puis systèmes agentiques — et le schéma de surpromesse est constant. Le fournisseur vend l’amélioration de la décision ; six mois plus tard, le client découvre la traîne des coûts d’intégration et de maintenance, et le délai de retour sur investissement double discrètement.

Mais le test économique que j’utilise réellement ne porte pas sur la fréquence ou le coût pris isolément. Il porte sur la simultanéité, et c’est la partie de l’équation que la plupart des acteurs de cette industrie comprennent encore mal. Une bonne équipe opérationnelle peut gérer correctement beaucoup de décisions, tant qu’elles se produisent l’une après l’autre. Ce qui met une équipe humaine en défaut, et ce pour quoi les logiciels de planification conventionnels n’ont jamais été conçus, c’est un ensemble de décisions qui évoluent toutes en même temps et qui interagissent toutes entre elles. Une modification de la capacité d’un site change la bonne réponse pour un autre site situé trois États plus loin, dans la même heure, tandis qu’un retard fournisseur modifie simultanément la contrainte d’une troisième décision. Personne, aussi compétent soit-il, ne peut conserver tout cela en tête au même moment. Ce n’est pas un problème de volume. C’est un problème de simultanéité, et il est mal compris précisément parce que la plupart des automatisations, RPA comprise — fondée sur des règles — ont été conçues pour accélérer une décision à la fois, et non pour garder en vue plusieurs décisions interdépendantes.

C’est là que l’économie réelle apparaît, et c’est aussi mon véritable seuil. Une décision prise deux fois par an par trois personnes expérimentées réunies dans une salle n’est pas une candidate, quelle que soit la valeur en jeu, parce qu’il n’y a aucune simultanéité sur laquelle un système pourrait apporter de la valeur. En revanche, un ensemble de décisions réellement interdépendantes, où la bonne réponse à un endroit dépend de ce qui se passe à trois autres endroits au même moment, est précisément le point où même une excellente équipe opérationnelle finit par manquer de capacité, quel que soit son talent, et où l’effet de réseau commence réellement à se multiplier au lieu de simplement s’additionner.

Si je ne peux pas identifier ce type de simultanéité — plusieurs décisions, plusieurs sites, qui bougent et interagissent tous en temps réel — je dis au prospect de ne pas acheter. Nous avons déjà renoncé à des contrats pour cette raison. Une décision unique et isolée n’a pas besoin d’un système agentique. Elle a besoin d’un bon tableur et de quelqu’un qui connaît le métier.

Shail Khiyara

L’exactitude n’est pas la frontière. Un système peut avoir raison 98 % du temps et ne toujours pas mériter les clés si les 2 % d’erreurs restantes sont du type que l’entreprise ne peut pas annuler. À l’inverse, un système avec un historique beaucoup plus court peut gagner la confiance plus tôt si une erreur ne coûte presque rien à corriger. La question n’a jamais été : à quelle fréquence a-t-il raison ? La question est : que se passe-t-il lorsqu’il a tort ?

C’est pourquoi la ligne que je refuse de déplacer est tracée autour des conséquences, et non du niveau de confiance. Du capital engagé au-delà d’un montant courant. Tout ce qui touche à la sécurité d’une personne. Tout ce qui comporte une exposition réglementaire ou de conformité, là où la règle existe parce que quelqu’un a été blessé avant que la règle n’existe. Ce ne sont pas des domaines où je veux qu’un système optimise le chiffre pour lequel il a été entraîné sans qu’une personne soit présente pour demander si ce chiffre signifie toujours ce que nous croyons qu’il signifie.

Voici ce que je dirais à n’importe quel dirigeant qui réfléchit à cette question, pas seulement à vous. J’ai souvent dit publiquement : le silicium (l’IA) a besoin du carbone (les humains). Un modèle peut tenir compte de mille variables à la fois sans jamais se fatiguer. Il ne peut pas sentir qu’un problème arrive avant que les données ne le montrent, et il n’a jamais eu à regarder quelqu’un dans les yeux pour lui expliquer une décision qui lui a coûté quelque chose. Cet instinct n’est pas un jeu de données que nous attendons encore de collecter. C’est une autre forme d’intelligence, et les décisions que je viens de citer sont exactement celles pour lesquelles cette forme d’intelligence doit encore apposer sa signature.

La responsabilité suit la même logique. Lorsqu’une entreprise autorise délibérément un agent à franchir cette ligne et que cela tourne mal, la responsabilité ne se déplace pas vers le système. Elle reste auprès de la personne qui a fixé le seuil ayant permis au système d’agir : une personne nommément identifiable, pas « l’IA » et pas « le fournisseur ». Nous le disons aux clients avant même de discuter d’un élargissement de l’autonomie sur une décision. Si personne dans la pièce n’est prêt à mettre son nom sur cette responsabilité, nous n’élargissons pas l’autonomie.

Le silicium peut porter le poids du calcul. Il ne peut pas porter le poids de la conséquence. Cela reste à notre charge.

Shail Khiyara

Quelques éléments me viennent à l’esprit. La confiance mesurée par les overrides est essentielle : sur les décisions pour lesquelles l’IA agentique industrielle est en production depuis au moins six mois, le taux de décisions annulées ou modifiées par l’humain doit diminuer sur la période, et non rester plat. Aujourd’hui, chaque recommandation passe par un humain avant d’être mise en œuvre. C’est la bonne approche aujourd’hui. Si, dans 24 mois, les personnes qui approuvent ces recommandations les modifient toujours au même rythme qu’au premier jour, alors le système ne gagne pas la confiance : il est simplement toléré, et je devrais reconnaître que la technologie ne fait pas ce qu’elle prétend faire.

Par ailleurs, aujourd’hui, la plupart des systèmes d’IA industrielle exécutent avec une validation humaine préalable. Je m’attends à ce que cela change pour un ensemble défini de décisions à faible conséquence et réversibles : ajustements de prix, réallocations courantes, décisions peu coûteuses à annuler si nous nous trompons. Je suis prêt à parier que ce chiffre s’éloignera nettement de zéro dans les 24 prochains mois. S’il reste à zéro partout, pour tout le monde, dans deux ans, ce ne sera plus de la prudence. Ce sera le signe que la thèse ne tient pas.

Les industries agroalimentaires et manufacturières voient leur main-d’œuvre expérimentée vieillir. Une génération d’opérateurs qui a passé trente ans à apprendre à quoi ressemble une mauvaise récolte, ou ce qu’un accord collectif autorise réellement avant même que quelqu’un n’en lise les petites lignes, part à la retraite, et l’essentiel de ce jugement quitte l’entreprise avec eux. Je veux mesurer quelle part de ce jugement survit à leur départ dans les bibliothèques de contraintes que nous construisons avec eux tant qu’ils sont encore présents. Appelons cela un taux de rétention des connaissances. Si un opérateur chevronné part à la retraite et que, six mois plus tard, les décisions prises avec un système d’IA industrielle sont sensiblement moins bonnes sans lui, nous n’avons rien capturé de réel : nous avons simplement construit une interface plus élégante au-dessus d’une personne. S’il part et que le système continue à prendre les décisions qu’il aurait prises, alors quelque chose de durable a été transmis avant son départ. Je sais que cette formulation met certaines personnes mal à l’aise : elle donne l’impression que je parle de numériser une personne. Je préfère appeler les choses par leur nom. L’alternative n’est pas que la connaissance reste humaine. L’alternative est qu’elle parte à la retraite et disparaisse tout simplement.

Shail Khiyara

D’ici 2030, le changement le plus important ne sera pas ce qui sera automatisé. Ce sera ce dont un directeur d’usine ou un analyste supply chain sera réellement responsable une fois disparue la partie de son travail consacrée à la collecte d’informations. Aujourd’hui, une grande partie de ce rôle consiste à réconcilier des données dispersées avant même qu’une véritable décision puisse être prise. Retirez cela, et ce qui reste comporte moins de tâches mais des enjeux plus lourds : les cas limites, les arbitrages sans réponse propre, le moment où une contrainte qui n’a jamais figuré dans aucun modèle — une relation sociale, un instinct de sécurité, une promesse faite à une communauté — doit l’emporter sur l’optimisation. Je pense que ce basculement est déjà irréversible. Une fois qu’une organisation a vu ce que ses meilleurs collaborateurs peuvent accomplir lorsqu’ils ne sont plus enterrés sous le travail de réconciliation des données, elle ne choisit pas volontairement de les y replonger.

La partie que je me battrais pour garder humaine, même à un coût, est celle dont nous avons parlé plus tôt : le droit de dire non, et d’avoir raison, sans devoir expliquer ce non dans un langage qu’un modèle peut analyser. À partir du moment où une entreprise exige d’un opérateur qu’il justifie une décision de passer outre dans des termes que le système comprend, le système est discrètement devenu le véritable décideur et la personne une fonction de conformité portant un badge. Je préférerais conserver cela plus lent et plus coûteux plutôt que d’y renoncer, parce que l’alternative n’est pas une version plus rapide du bon jugement. C’est l’absence de jugement, mieux emballée.

Il y a une deuxième chose que je préserverais, et c’est la plus difficile. Dans chaque usine, quelque part, il existe une personne qui sait qu’un problème « sent mauvais » avant que les données ne le confirment : trente ans de reconnaissance de motifs que personne n’a jamais consignés parce que personne n’a pensé à les demander. Nous pouvons capturer une partie de cela dans une bibliothèque de contraintes si nous le faisons délibérément tant que ces personnes sont encore là. Nous ne pouvons pas capturer la partie qui n’existe que lorsqu’une personne choisit, à un instant précis, de faire davantage confiance à son intuition qu’au chiffre affiché à l’écran. Cette capacité — passer outre le système et l’assumer — n’est pas une fonctionnalité que j’essaie de construire. C’est ce que tout le système est censé servir. Le silicium a besoin du carbone. Si nous oublions un jour lequel des deux commande, nous n’aurons pas construit une entreprise plus intelligente. Nous aurons simplement construit une manière plus rapide de nous tromper.