Tout le monde aura l’IA. Très peu auront codifié la façon dont leur entreprise fonctionne vraiment.

Les manufacturiers et les distributeurs n’existent pas pour faire fonctionner des logiciels. Ils existent pour fabriquer et acheminer les produits dont leurs clients ont besoin, offrir un service à la clientèle exceptionnel et s’étendre à de nouveaux marchés où ils peuvent répondre à la demande.

Pour réussir, ils doivent bâtir une entreprise capable de le refaire, encore et encore, de façon rentable.

Jusqu’à aujourd’hui, cela se heurtait à une limite ferme : les gens. Plus de commandes voulait dire plus d’opérations, et plus d’opérations voulait dire plus de personnel. La capacité humaine a été le goulot d’étranglement de la croissance, et son coût, l’un des plus lourds qu’une entreprise ait à porter.

Je crois que c’est là que la conversation sur l’IA en entreprise devrait commencer. Pas par ce qu’un modèle sait faire, mais par ce dont nous voulons que les opérations deviennent capables.

Je crois que l’IA deviendra largement accessible beaucoup plus vite que la plupart des entreprises ne le pensent. Lire un bon de commande, faire correspondre des codes de produits, préparer une soumission ou extraire une transaction de l’ERP ne constituera pas, en soi, un avantage durable.

Ces capacités comptent quand elles aident quelqu’un à servir un client, à tenir un engagement ou à prendre une meilleure décision. Les relier à l’entreprise, c’est là le travail le plus difficile.

Donner à l’IA l’accès à vos systèmes, ce n’est pas la même chose que donner aux personnes et à l’IA une meilleure façon de mener les opérations.

Le but n’est pas d’avoir plus d’outils

Les entreprises industrielles ont investi dans des ERP, mis leurs machines sous surveillance, migré leur infrastructure vers le cloud et réorganisé leurs logiciels autour de services.

Ces programmes ont apporté de la valeur. Les données, les contrôles, l’infrastructure et l’intégration comptent. Ce qu’ils n’ont pas apporté, c’est de la valeur opérationnelle. Ils étaient coûteux et complexes, et l’écart entre ce que la technologie pouvait faire et ce dont les opérations avaient réellement besoin est resté grand ouvert. C’est à cause de cet écart que tant d’entre eux ont laissé le souvenir de mauvais projets.

Cela se répète pour une raison. L’entreprise achète un outil, puis demande à ses gens de plier autour de lui le processus voulu. Le résultat visé était clair. Comment, où et quand utiliser l’outil pour y arriver, c’était à chacun de le découvrir. Voilà pourquoi le même processus finit par être mené de trois façons différentes par trois personnes différentes.

Si nous ne changeons rien, l’IA répétera l’histoire. Un outil de plus, la même improvisation, en accéléré.

Mais il y a ici une occasion qui n’existait pas avant. Nous pouvons définir le processus que nous voulons et le faire exécuter exactement comme prévu, en faisant appel, en coulisse, à l’outil quand il le faut. L’outil dictait le processus. Désormais, le processus peut dicter l’outil.

La question n’a jamais été la quantité de technologie qu’une entreprise peut déployer. C’est de savoir si cette technologie se traduit vraiment par un gain opérationnel.

Le travail entre les systèmes

Prenons la création de commandes. Les ventes sont le sang d’une entreprise, et c’est ici que l’intention du client devient un engagement opérationnel.

Inscrire les produits et les quantités, c’est la partie facile. Quelqu’un doit comprendre ce que le client veut dire, si le produit proposé convient à l’application et ce que l’entreprise peut réellement promettre.

Prenez une demande que tout le monde connaît : un client utilise l’ancien nom d’un produit, demande la même configuration qu’à un achat précédent ou a besoin d’une solution de rechange pour un article non disponible. L’information contenue dans la demande ne suffit pas. La personne qui la traite a besoin de l’historique et de ce qui a motivé le choix.

C’est le premier problème. La connaissance opérationnelle nécessaire pour bien faire le travail ne se trouve nulle part dans les systèmes. Elle se trouve dans les conversations avec les clients, dans l’expérience, dans le jugement de la personne vers qui tout le monde se tourne quand la réponse n’est pas claire.

Le deuxième problème, ce sont les systèmes eux-mêmes. Pour accomplir une seule tâche, une personne jongle avec plusieurs applications legacy, où règles et conditions sont enfouies dans du code sur mesure qu’aucun agent ne peut trouver. Elle doit savoir quel système utiliser, quand et comment. Ce savoir n’est écrit nulle part, lui non plus.

Les deux mêmes problèmes se retrouvent dans la planification, l’approvisionnement, la production, la logistique et le service à la clientèle. La tâche change. L’écart, lui, demeure.

Un agent peut avoir accès à toutes les fiches et manquer quand même de ce qu’il faut pour agir de façon responsable.

L’expertise devrait survivre à l’expert

Jusqu’ici, les gens ont été l’actif le plus précieux d’une entreprise industrielle, et pour une bonne raison : ce sont eux qui détiennent la connaissance opérationnelle et l’expertise sur lesquelles repose l’entreprise.

C’est aussi là le risque. Quand l’expertise s’en va, le savoir s’en va avec elle.

Ce qui est nouveau, c’est que nous pouvons désormais transformer ce savoir en autre chose. La connaissance opérationnelle n’est pas figée. Elle change avec chaque client, chaque exception, chaque correction. Pour la première fois, cette expertise en constante évolution peut devenir un actif qui appartient à l’entreprise et où toute l’organisation peut puiser. Je crois que les entreprises qui bâtiront cet actif en premier détiendront un avantage que les autres ne pourront pas acheter.

Pensez à la façon dont une personne apprend vraiment son métier. Pas dans un manuel. Elle apprend en utilisant les outils, en faisant le travail, en saisissant le contexte, en se trompant et en se faisant corriger. L’expertise se bâtit par l’usage.

Un système devrait apprendre de la même façon. On peut capter une partie du savoir dans des ateliers et de la documentation, mais il est impossible de tout capter à l’avance. Une partie ne devient visible que lorsque quelqu’un corrige une recommandation ou explique pourquoi la réponse habituelle ne fonctionnera pas.

Chaque correction est une occasion de conserver cette compréhension. Qui l’a faite ? Pour quelle raison ? S’applique-t-elle à cette commande, à ce client ou à un ensemble plus large de situations ? Que faut-il valider avant que quiconque s’y fie de nouveau ?

Capter une réponse sans sa portée ne fait que rendre la mauvaise réponse plus facile à répéter.

C’est pourquoi la technologie doit être présente là où le travail se fait. Le but est de mieux outiller la personne suivante, plutôt que de lui demander de reconstruire le même savoir à partir de zéro.

Nous avons vu ce que cela change. Dans un déploiement, il fallait 24 heures de formation simplement pour prendre une commande. Il faut maintenant moins d’une heure.

C’est un résultat de formation, et il annonce quelque chose de plus grand : une expertise disponible au moment même du travail. La formation compte toujours. Les gens développent toujours leur jugement. Mais une entreprise ne devrait pas avoir à reconstruire l’accès à son propre savoir à chaque nouvelle embauche.

L’humain n’est pas le plan de secours

Il existe un récit séduisant sur l’adoption de l’IA : d’abord, l’humain est « in the loop », puis « on the loop », et finalement, il n’y a plus d’humain du tout.

Ce n’est pas l’ambition que je choisirais pour des opérations industrielles critiques, parce que remplacer les gens n’a jamais été le but.

Le but, c’est d’exploiter la capacité humaine à son plein potentiel. Chaque tâche inutile, répétitive ou qui ne crée aucune valeur devrait disparaître du bureau des gens. Ce qui reste, c’est le travail qui est à leur mesure : le client, l’arbitrage, la décision qui relève du jugement. On aura toujours besoin des gens, et dans les domaines qui comptent le plus, on en aura besoin plus que jamais.

Une partie du travail devrait donc être automatisée. Une autre, préparée par l’IA et approuvée par une personne. Une autre encore devrait suivre un processus fixe et prévisible. Et parfois, une interface familière l’emporte sur une conversation avec un agent.

Le but n’est pas de maximiser la part du travail faite par l’IA. C’est d’augmenter ce que les opérations peuvent accomplir, et ce que leurs gens sont libres d’y apporter.

Cela demande plus que de donner à un employé un assistant de plus à qui poser des questions. Les personnes et l’IA ont besoin d’un espace partagé pour faire le travail. La personne devrait voir ce qui est proposé, quelle information l’appuie, ce qui reste incertain et ce qui se passe si elle approuve. Elle devrait pouvoir corriger la proposition sans perdre le contexte ni recommencer ailleurs.

La lecture qu’un représentant fait d’un client, le jugement d’un planificateur sur un engagement, la relation d’un employé avec un fournisseur : rien de tout cela n’est un obstacle à l’automatisation. Cela fait partie de ce que l’entreprise vend.

L’humain n’est pas le plan de secours. L’humain fait partie du modèle opérationnel.

Les opérations devraient s’améliorer d’elles-mêmes

Voici ce sur quoi, je pense, nous nous trompons depuis longtemps. L’amélioration opérationnelle a été traitée comme un projet TI, alors qu’elle est une décision d’affaires qui revient à chaque service.

Les gens qui font tourner les opérations savent exactement ce qui ne fonctionne pas et ce qui pourrait être mieux. Ils l’ont toujours su. Ce qu’ils n’ont jamais eu, c’est un moyen d’agir. Chaque correctif devait être traduit en exigence, mis en file d’attente derrière d’autres priorités, confié à une équipe qui ne vit pas le problème, puis livré des mois plus tard sous une forme qui s’était éloignée de l’intention de départ. C’est de là que viennent les malentendus entre les équipes. C’est pour cela que l’adoption échoue.

L’ambition, c’est donc des opérations qui s’améliorent d’elles-mêmes. Un système qui reconnaît quand la même précision est demandée encore et encore, quand une recommandation est sans cesse corrigée, quand une approbation ajoute un délai sans changer la décision, et qui peut proposer le changement. Ensuite, le service responsable du travail décide si ce changement est utile.

Le critère n’est pas qu’un agent ait accompli une tâche. C’est que le client ait reçu le bon produit, que l’engagement ait été tenu, ou que l’équipe ait cessé de perdre du temps sur le même problème évitable.

Avec le temps, je crois qu’une partie de cette amélioration pourra se faire d’elle-même, à l’intérieur de limites que l’entreprise a approuvées. D’autres changements exigeront encore du jugement humain, des tests ou une revue technique. L’autonomie doit naître d’un contexte fiable, de permissions explicites et de la preuve que le changement est utile. Un système ne devrait jamais confondre la façon de faire parallèle d’une seule personne avec une règle que tout le monde doit suivre.

Les TI conservent un rôle essentiel en matière de sécurité, d’accès, d’architecture et des contrôles qui rendent tout cela possible. Ce qui change : améliorer une règle autorisée n’exige plus d’ouvrir un projet.

Bâtir autour des opérations

C’est ce que nous construisons chez Frontleap : une couche d’exécution intelligente pour les manufacturiers et les distributeurs.

Elle réunit trois responsabilités autour du travail.

Capter la connaissance opérationnelle qui ne se trouve nulle part dans vos systèmes.

Donner aux personnes et à l’IA un seul endroit pour agir ensemble à partir de celle-ci.

Donner aux opérations le pouvoir de s’améliorer, d’apprendre et de grandir d’elles-mêmes.

Ces trois responsabilités vont ensemble. Le savoir capté sans passage à l’action devient un dépôt de plus que personne n’ouvre. Une interface d’IA sans contexte oblige les gens à vérifier chaque réponse. L’amélioration sans résultats optimise l’activité plutôt que l’entreprise.

L’ERP demeure essentiel. Frontleap fonctionne aux côtés de SAP sans le modifier. Nous bâtissons sur les systèmes auxquels les entreprises font déjà confiance, et nous changeons la façon dont les personnes et l’IA travaillent avec eux.

Nous commençons par les commandes, parce que c’est là que le lien avec le client est immédiat. Qu’a-t-il demandé ? À quoi pouvons-nous nous engager ? Que doit-il se passer ensuite ?

L’avenir que nous construisons

Des personnes et des agents qui travaillent côte à côte sur la même tâche, chacun prenant en charge ce qu’il fait le mieux, et un travail accompli de la façon la plus efficace possible.

La connaissance opérationnelle, les règles d’affaires et leurs conditions d’application : non plus dans la tête des gens, mais conservées comme un actif durable où puise toute l’entreprise.

Des opérations qui ont la maîtrise des outils et des systèmes qu’elles utilisent, pour que les logiciels qui font tourner le travail soient véritablement conçus pour ce travail.

Des opérations qui apprennent en travaillant, qui découvrent des occasions qu’elles ne pouvaient pas voir avant, et qui enrichissent leur propre expertise à chaque tâche accomplie.

Des systèmes centraux améliorés, optimisés ou remplacés en arrière-plan, sans jamais changer la façon dont le travail se fait sur le plancher.

Ce n’est pas une expérience de pensée. C’est exactement ce que nous construisons.

La technologie devrait servir les opérations. Elle devrait rendre l’entreprise plus efficace. Elle ne devrait pas lui dicter sa façon de fonctionner.

Les modèles seront partout. Les agents deviendront banals. Ce que votre entreprise sait de la façon dont elle fonctionne vraiment, non.