Depuis sa mise à disposition générale en mai 2025, le Process Copilot de Celonis promet de rendre les données de process mining accessibles à travers une simple conversation. Ce que la réalité du terrain nous enseigne, sur un cas concret.
Officiellement, un Process Copilot est un asset Studio que l'on connecte à un Knowledge Model existant (documentation officielle). Une fois configuré, il permet d'interagir avec les données Celonis à travers une interface conversationnelle. L'utilisateur pose une question en langage naturel, et l'assistant lui répond sous forme de texte, de tableau, de graphique ou d'insight actionnable.
Sous le capot, le Process Copilot est ce que Celonis appelle un système agentique (System Card officielle). Un modèle de langage reçoit la question de l'utilisateur, construit un plan d'exécution, choisit parmi un ensemble d'outils prédéfinis (chargement de données, affichage de KPI, création de graphique, recherche), exécute, itère si nécessaire, puis formule une réponse. Le tout s'appuie sur le Knowledge Model, qui décrit les données du processus, leur signification métier et leurs relations.
Celonis insiste sur un point important dans sa documentation officielle : la qualité et la pertinence des réponses dépendent directement du périmètre et de la précision de la connaissance configurée.
Le projet dont il est question ici est mené au sein d'un grand groupe international, sur un processus clé de la fonction finance, le cycle Procure-to-Pay. Ce processus couvre l'ensemble des opérations, depuis l'émission de la commande d'achat jusqu'au paiement final du fournisseur, en passant par la réception, la validation des factures et la gestion des éventuels blocages. Il s'inscrit dans un environnement ERP cloud largement répandu dans les grandes entreprises.
Les questions typiques que nous cherchons à couvrir tournent autour du quotidien opérationnel. Cette facture est-elle payée, et si oui à quelle date ? Pourquoi celle-là est-elle bloquée, et qui doit intervenir pour la débloquer ? Quels avoirs sont disponibles pour ce fournisseur ? Quelle est la position nette d'un fournisseur ? Une commande a-t-elle été surfacturée ?
L'équipe cible est composée d'utilisateurs opérationnels, sans profil technique, habitués à leur ERP et à Excel. L'assistant doit leur répondre dans leur langue, avec un ton clair, sans jargon, et surtout avec des réponses fiables et exploitables immédiatement.
Plusieurs chantiers ont été menés en parallèle sur le projet. Voici les principaux.
Le premier chantier concerne le choix du modèle de langage utilisé par l'assistant. Nous avons rapidement basculé d'un modèle de conversation générique vers un modèle de raisonnement plus avancé. La différence est immédiate : moins de règles explicites à écrire dans le prompt, une meilleure compréhension des cas complexes, une capacité à croiser plusieurs sources avant de conclure.
Le deuxième chantier porte sur le cadrage du Knowledge Model. Il s'agit d'exposer sélectivement les tables et les champs nécessaires à l'assistant, ni trop peu, ni trop. Chaque champ est accompagné d'une description métier claire, qui devient sa boussole quand il choisit quoi interroger.
Le troisième chantier, le plus long, est la rédaction du system prompt. On y définit le rôle de l'assistant, les règles de comportement, la terminologie métier, le format de réponse attendu, les cas particuliers à traiter. Ce prompt évolue continuellement au fil des tests utilisateurs.
Certaines difficultés ne se voient pas au démarrage. Elles apparaissent uniquement quand on confronte l'assistant à la réalité du terrain. Voici les trois qui nous ont le plus marqués.
Un même champ peut refléter un état périmé. Un utilisateur demande une fois "cette facture est-elle bloquée ?". L'assistant regarde le champ le plus évident, indique un blocage actif, alors qu'il a été levé la veille dans l'ERP. Le champ n'est pas mis à jour en temps réel. Il faut alors indiquer à l'assistant d'aller croiser plusieurs sources avant de conclure.
Comparer sans comprendre le contexte peut créer de fausses alertes. Un jour, l'assistant conclut qu'une commande est surfacturée : le montant de la commande est de 1 000 euros, celui de la facture 1 200 euros. Sauf que la commande est en hors taxes et la facture en toutes taxes comprises. L'écart correspond simplement à la TVA. Sans règle métier claire dans le prompt, l'assistant multiplie ces alertes erronées.
Un LLM n'est pas déterministe. Un collègue teste "combien de factures reçues de Cap Gemini en 2026 ?". L'assistant ne trouve pas. Une heure plus tard, avec la même question, il trouve. La différence, c'est juste l'orthographe testée par le modèle : "Capgemini" en un mot, ou "Cap Gemini" en deux. Il faut donc lui apprendre à essayer plusieurs variantes avant de conclure à un "non trouvé".
Ces trois exemples ont un point commun. À chaque fois, l'assistant a répondu quelque chose de techniquement correct au regard des données qu'il voyait, mais de faux au regard du métier. C'est là que le travail de configuration se joue vraiment.
Face à ces difficultés, plusieurs leviers font la différence.
Créer des champs synthétiques qui portent la logique métier. Plutôt que de laisser l'assistant reconstituer une règle complexe à chaque question, on précalcule un champ qui donne directement l'information. Dans notre cas, un indicateur "blocage actif oui/non", calculé à partir de plusieurs sources croisées, a permis à l'assistant de répondre correctement à la question "cette facture est-elle bloquée ?" sans avoir à recroiser les données à chaque appel.
Documenter la terminologie métier dans le prompt. Les utilisateurs parlent leur langage. Un "avoir disponible", une "position nette fournisseur", une "MEP" ne sont pas des termes qui figurent dans la documentation de l’ERP. Sans définition explicite dans le prompt, l'assistant improvise, et improvise mal. Un glossaire métier est indispensable.
Forcer l'assistant à demander confirmation en cas de doute. Face à une ambiguïté (une facture non trouvée, un fournisseur à l'orthographe incertaine, un montant qui pourrait correspondre à plusieurs commandes), l'assistant a naturellement tendance à choisir la réponse la plus probable et à la présenter comme certaine. Il a fallu lui imposer une règle simple : en cas de doute, poser la question à l'utilisateur avant de répondre.
Contraindre la structure des réponses. Un format constant, avec le statut en premier, les détails ensuite, un conseil actionnable, et un indice de certitude à la fin, aide les utilisateurs à repérer l'essentiel rapidement. L'indice de certitude, en particulier, est un signal précieux : il indique quand la réponse mérite d'être creusée avant d'agir.
Impliquer les utilisateurs métier à chaque itération. Sans leurs retours, on optimise dans le vide. Ce sont eux qui repèrent les cas limites, les incohérences, les nuances métier oubliées.
Un Process Copilot Celonis n'est pas une baguette magique. C'est un modèle de langage branché sur un modèle de connaissance. Sa valeur ne vient pas du modèle en lui-même, mais de tout ce qu'on met autour : la qualité des données, la précision des règles métier, la terminologie explicitée, et l'implication des utilisateurs à chaque itération.
C'est un travail moins spectaculaire que ce que promet parfois le marketing autour de l'IA. Il ressemble davantage à de l'artisanat qu'à de la magie, et il n'est jamais réellement terminé : les données évoluent, les processus changent, les questions se raffinent. Mais c'est aussi ce qui fait la différence entre un assistant qui séduit à la démo, et un assistant qui restera utilisé dans la durée.
