
La désillusion la plus fréquente dans les organisations est la suivante : on s'enthousiasme pour l'IA générative avec ChatGPT ou Microsoft Copilot, on lit un article expliquant que l'IA peut « améliorer votre entreprise d'une manière ou d'une autre », on cherche d'autres cas d'usage où plaquer un chatbot, et on finit déçu quand les résultats ne sont pas vraiment satisfaisants. Puis vient la phase de justification. J'entends souvent : « Le modèle n'est pas assez bon » ou « Il faut former les gens à écrire de meilleurs prompts. »
Dans 90 % des cas, ce ne sont pas les bonnes conclusions. Elles viennent du fait que nous pensons en chatbots. J'ai développé plus de trois douzaines d'applications d'IA générative, pour des organisations de trois personnes comme pour des groupes mondiaux de plus de trois cent mille salariés, et j'ai vu ce schéma partout.
Des milliers d'entreprises vous disent qu'il vous faut « une solution de chatbot » parce que tout le monde en a une. OpenAI avec ChatGPT, Microsoft Copilot, Google avec Gemini et tous les autres vendeurs de chatbots font un excellent travail pour lever les premières barrières à la création d'un chatbot. Mais je vous le dis : 75 % des problèmes vraiment douloureux que l'IA générative peut résoudre ne gagnent rien à prendre la forme d'un chatbot.
Trop souvent, je vois des managers, des directeurs de programme ou d'autres décideurs partir de cette idée : "Nous avons un produit d'IA qui permet de créer des chatbots. Trouvons le plus d'endroits possible où le déployer." D'après mon expérience, c'est la mauvaise approche : on part d'une solution et on essaie d'y faire entrer un problème existant. La bonne démarche consiste à examiner un problème, à l'analyser et à trouver une solution d'IA adaptée. Un chatbot peut être une bonne interface pour certains cas d'usage, mais forcer chaque problème dans un chatbot pose problème.

Imposer une solution à un problème vs. partir du problème pour trouver une solution. (c) Marcel Müller 2024
Dans cet article, je partage les enseignements et la méthode que j'ai développés en construisant d'innombrables applications. Ces applications, aujourd'hui en production au service de milliers d'utilisateurs, ont façonné ma manière de concevoir des solutions d'IA générative utiles, au lieu de suivre aveuglément une tendance et d'être déçu quand elle ne fonctionne pas.
Je vous dis de ne pas partir des chatbots. Alors par où commencer ? La réponse est simple : les processus métier.
Tout ce qui se passe dans une entreprise est un processus métier. Un processus métier combine différentes activités (« unités de travail »), des événements (par exemple des erreurs) et des passerelles (par exemple des décisions) reliés en un workflow [1]. Il existe des outils pour modéliser les processus métier [2] sous des formes de diagrammes bien connues, et toute une discipline de recherche consacrée à leur analyse et à leur amélioration [3][4][5]. Le Business Process Management est un bon outil parce qu'il n'a rien de théorique : il est utilisé partout dans les entreprises, même quand elles ne savent pas le nommer.
Prenons un exemple. Imaginez que votre entreprise réalise des expertises immobilières pour une banque. Avant d'accorder un prêt hypothécaire, les banques demandent à des experts d'estimer la valeur du bien, afin de connaître son prix réel si le prêt ne peut pas être remboursé.
Rédiger un rapport d'expertise immobilière est un grand processus métier que l'on peut décomposer en sous-processus. En général, l'expert se rend sur place, prend des photos, puis rédige un rapport de 20 à 30 pages. Ne tombons pas, pour une fois, dans le réflexe « oh, un rapport de 20 à 30 pages, je m'installe devant ChatGPT et j'irai sûrement plus vite ». Souvenez-vous : d'abord les processus, ensuite la solution.
On peut décomposer ce processus en sous-processus plus petits : se rendre sur place, prendre des photos, puis rédiger les différentes parties du rapport, à savoir la description de l'emplacement, puis l'état et la surface des différentes pièces. En regardant de plus près un seul processus, on voit les tâches, les passerelles et les événements impliqués. Pour décrire l'emplacement, par exemple, l'expert s'assoit à son bureau, fait des recherches, regarde sur Google Maps les commerces alentour et consulte le plan des transports de la ville pour évaluer la desserte du bien et l'aspect de la rue. Ce sont autant d'activités (ou de tâches) que le chargé de dossier doit accomplir. Si le bien est une ferme isolée au milieu de nulle part, les transports en commun sont sans doute sans intérêt, car les acheteurs de ce type de bien dépendent de toute façon de la voiture. Cette décision sur le chemin à suivre dans un processus s'appelle une passerelle.

Processus actuel de l'exemple, modélisé en BPMN 2.0. (c) Marcel Müller 2024
Cette approche pilotée par les processus commence par évaluer le processus actuel avant d'y appliquer la moindre IA.
Avec cette analyse de nos processus et de notre objectif, nous pouvons maintenant voir à quoi devrait ressembler un processus avec IA. Il est important de réfléchir à chaque étape. Si l'on se concentre uniquement sur le sous-processus de rédaction de la description, cela peut donner :
Et oui, on peut le faire de manière interactive avec un chatbot, en travaillant avec un « partenaire IA » jusqu'à obtenir le résultat. Mais en entreprise, cela pose trois problèmes majeurs :
Ces problèmes tiennent aux fondements mêmes des LLM qui animent les chatbots.

Interaction avec un chatbot (à gauche) vs. orchestration d'un processus prédéfini et reproductible (à droite). (c) Marcel Müller 2024
Au lieu de s'appuyer sur un cycle « prompt, réponse », les applications d'entreprise devraient être conçues comme une suite d'étapes orchestrées, (en partie) pilotées par l'IA, chacune visant un objectif précis. Un utilisateur pourrait par exemple déclencher un processus en plusieurs étapes qui combine différents modèles et éventuellement des entrées multimodales pour des résultats plus efficaces, en associant ces étapes à de petits scripts qui récupèrent des données sans IA. En intégrant le Retrieval-Augmented Generation (RAG) et en réduisant les interventions humaines, on crée des workflows plus puissants et plus automatisés.
Cette orchestration apporte des gains d'efficacité importants par rapport à une orchestration manuelle via une interface interactive. Par ailleurs, toutes les étapes du processus ne doivent pas reposer uniquement sur un modèle d'IA. Dans l'exemple ci-dessus, nous avons constaté qu'utiliser l'API Google Maps pour trouver les arrêts et stations à proximité est nettement supérieur en qualité à l'interrogation d'un bon LLM comme GPT-4o, ou même d'un moteur RAG de recherche web comme Perplexity.
Pensons un instant à une époque sans IA. Les processus manuels peuvent prendre beaucoup de temps. Supposons qu'une tâche prenne une heure à la main et que le processus soit répété quatre fois : quatre heures au total. Un chatbot basé sur l'IA générative pourrait faire gagner 50 % (ou un autre pourcentage) du temps. Mais le temps restant est consacré à formuler des prompts, attendre les réponses et garantir la qualité par des corrections et des ajustements. Peut-on faire mieux ?

Gain de temps : processus manuel vs. automatisation par chatbot. (c) Marcel Müller 2024
Pour les tâches répétitives, malgré le gain de temps, devoir formuler des prompts, attendre et ajuster les résultats pour les harmoniser pose problème dans les organisations où plusieurs personnes exécutent le même processus. Pour y remédier, le recours aux modèles de processus devient essentiel.
Avec des modèles, les processus sont généralisés et paramétrés pour être réutilisables. L'effort de création d'un modèle de qualité n'est fourni qu'une fois, tandis que l'exécution de chaque cas devient bien plus efficace. Le temps passé à rédiger des prompts, contrôler la qualité et ajuster les résultats diminue fortement. C'est la différence fondamentale entre les solutions à base de chatbot et l'orchestration de processus assistée par l'IA avec des modèles. Et cette différence a un impact énorme sur la qualité et la reproductibilité.

Les vrais gains des modèles de processus. (c) Marcel Müller 2024
De plus, nous disposons désormais d'un périmètre restreint pour tester et valider notre solution. Dans un chatbot où l'utilisateur peut saisir n'importe quoi, il est difficile de tester et d'établir la confiance de manière quantifiable . Plus nous définissons et limitons les paramètres et fichiers qu'un utilisateur peut fournir, mieux nous pouvons valider une solution de façon quantitative.
Utiliser des modèles dans des processus assistés par l'IA reprend les principes d'un moteur de processus métier (Business Process Engine) en gestion des processus classique. Quand un nouveau cas se présente, ces moteurs puisent dans un référentiel de modèles et sélectionnent celui qui correspond. Pour l'orchestration, on renseigne ensuite les paramètres d'entrée.
Dans notre exemple d'expertise immobilière, le modèle a trois entrées : le type de bien (maison individuelle), une série de photos de l'intérieur et l'adresse.
Le modèle de processus se présente ainsi :
Dans notre exemple, nous avons réalisé l'application avec la plateforme entAIngine et son outil no-code intégré.
Notez que dans ce processus, seule 1 étape sur 4 utilise un grand modèle de langage. Et c'est une bonne chose ! Car l'API Google Maps n'hallucine jamais. Ses données peuvent être obsolètes, mais elle n'« inventera jamais quelque chose qui semble plausible ». Ensuite, la personne qui supervise peut vérifier, car nous disposons désormais de vraies sources d'information à analyser et à valider.
En gestion des processus classique, les modèles réduisent la variabilité, garantissent la répétabilité et améliorent l'efficacité et la qualité (comme dans des méthodes telles que Six Sigma). C'est le même état d'esprit qu'il faut adopter ici.
Nous avons maintenant un processus qui utilise un LLM et règle bien des casse-têtes. Mais comment un utilisateur interagit-il avec lui ?
On peut réaliser un tel processus en codant tout à la main ou en utilisant un moteur de processus IA no-code comme entAIngine [6].
Quand on modélise des processus métier avec des modèles, les interactions peuvent prendre plusieurs formes. D'après mon expérience des 2 dernières années, pour 90 % des cas d'usage de l'IA générative, les interfaces suivantes sont pertinentes :
* Interface de recherche de connaissances : fonctionne comme un moteur de recherche capable de citer et de référencer ses sources.
* Interface d'édition de documents : associe le traitement de texte à l'accès aux modèles de processus, aux modèles d'IA et aux orchestrations.
* Interface de chat : pour un travail itératif et interactif.
* Orchestration intégrée sans interface dédiée (RPA) : s'intègre aux interfaces existantes via des API.
La question est finalement : quelle est la manière d'interagir la plus efficace ? Pour certains cas d'usage créatifs ou des tâches non répétitives, le chat peut être l'outil idéal. Mais souvent, ce n'est pas le cas. Souvent, l'utilisateur veut avant tout produire un document. Disposer des modèles dans un éditeur est alors très efficace. Et parfois, inutile de créer une interface isolée de plus si vous voulez enrichir une application existante avec de l'IA. Il s'agit simplement d'exécuter le bon processus, de récupérer ses données d'entrée dans l'application existante et d'afficher le résultat quelque part dans son interface.
Ces interfaces constituent la base de la majorité des cas d'usage de l'IA générative que j'ai rencontrés jusqu'ici, tout en permettant une intégration évolutive dans les environnements d'entreprise.
En passant de « Comment utiliser un chatbot IA partout ? » à « Quels processus comportent quelles étapes, et comment l'IA générative peut-elle servir dans ces étapes ? », les entreprises posent les bases d'un véritable impact de l'IA. Combinez l'IA avec les systèmes existants, et ne réfléchissez qu'ensuite au type d'interface dont vous avez besoin. Vous libérerez ainsi une efficacité dont les entreprises qui ne voient pas plus loin que les chatbots ne rêvent même pas.
[1] Dumas et al., "Fundamentals of Business Process Management", 2018
[2] Object Management Group. "Business Process Model and Notation (BPMN) Version 2.0.2." OMG Specification, Jan. 2014
[3] van der Aalst, "Process Mining: Data Science in Action", 2016
[4] Luthra, Sunil, et al. "Total Quality Management (TQM): Principles, Methods, and Applications." 1st ed., CRC Press, 2020.
[5] Panagacos, "The Ultimate Guide to Business Process Management", 2012
[6] www.entaingine.com