Au cours des deux dernières années, l’entreprise a acquis de nombreux outils d’intelligence artificielle : assistants conversationnels, extensions de rédaction, robots de service client et systèmes de questions-réponses internes. Pourtant, peu de capacités ont véritablement été consolidées. Les prompts restent stockés sur les ordinateurs personnels, les processus métiers sont éparpillés dans les coins des documents, après le déploiement des agents intelligents, il manque de retours et de révisions, et les collaborateurs clés se voient encore monopoliser leur temps par les mêmes types de demandes. Le problème n’est souvent pas que les modèles ne soient pas assez intelligents, mais plutôt que…Le système n’a pas conçu « travailler » comme une compétence de poste gérable.。
D’abord, clarifions : pourquoi la fenêtre de discussion ne peut-elle pas servir de poste ?
Le chatbot répond à une question puis s’arrête. Les tâches doivent assurer une continuité : collecte d’informations, évaluation des règles, appel aux systèmes, mise à jour du statut, et escalade en cas d’exception. Le remboursement des frais de voyage en est un exemple typique : l’utilisateur peut d’abord dire « Aidez-moi à effectuer le remboursement de mes frais de voyage », puis, au milieu, demander « Quel est le solde restant de mon plafond pour ce mois ? », avant d’ajouter ultérieurement une nouvelle facture. Si le système traite chaque interaction comme une nouvelle session, le flux se brise, le contexte se perd, et il devient impossible, a posteriori, de déterminer si l’erreur provient des règles ou de l’interface.
Dans l’industrie, il existe déjà des pratiques consistant à concevoir les agents intelligents comme de « véritables employés numériques » : on leur attribue un poste, un numéro d’employé, des limites de compétences et un historique de travail, auxquels s’ajoutent des SOP modifiables, une base de connaissances, des outils ainsi que des traces d’exécution. Du côté de l’open source, des solutions telles que StaffDeck, publiées par des organisations comme OpenBMB, présentent l’agent non pas comme un simple ensemble de prompts, mais comme une combinaison de ressources opérationnelles. Pour les entreprises qui développent ou personnalisent elles‑mêmes leurs systèmes, ce n’est pas tant le nom du produit qu’il convient d’emprunter, mais plutôt ce modèle d’objet.
Logique métier : le système doit comporter au moins sept types d’objets.
Pour développer un système d’employé numérique, commencez par intégrer les objets métier dans la spécification, puis abordez le choix du modèle.
- Dossier de poste: Nom ou nom de rôle, numéro d’employé, responsabilités, statut en ligne, destinataire du service. Sans dossier, les autorisations et l’évaluation n’ont aucun point d’ancrage.
- Frontière des capacités: Quels documents peuvent être consultés, quels champs peuvent être modifiés, et à quoi ne peut-on pas s’engager. Les limites doivent pouvoir être ajustées par l’administrateur, et non figées dans les instructions.
- SOP / Compétences liées aux processus: Décomposez les processus complexes en nœuds, avec prise en charge des branches conditionnelles, des appels à des outils, de la recherche de connaissances et du transfert vers un agent humain.
- Ontologie des connaissances: Les thèmes, les règles, les sources et le manuel d’utilisation sont stockés séparément ; les réponses doivent pouvoir être rattachées à leur source, et la recherche doit être ajustable.
- Intégration des outils: L’interface HTTP ou MCP sert à consulter les quotas, créer des documents et modifier les statuts, et non pas simplement à générer un simple texte.
- Tâche planifiée: Les tâches périodiques telles que le résumé quotidien, le rappel des délais dépassés et l’inspection des stocks ne doivent pas attendre que l’utilisateur prenne l’initiative.
- Traçabilité et retour d’information: Enregistrement des parcours, des étapes, des outils, des connaissances et des réponses ; les likes, les dislikes et la prise en charge manuelle sont transmis à la phase suivante de révision.
Une requête réelle comprend souvent plusieurs tâches. L’employé numérique doit d’abord accéder au SOP de remboursement, rassembler tous les champs et effectuer les vérifications de règles, puis passer au SOP de consultation des plafonds pour appeler l’interface. Si l’utilisateur interrompt le processus pour poser une question sur la politique, il convient de sauvegarder le nœud actuel et de reprendre le flux initial après avoir fourni la réponse. Pour les questions dépassant les règles, le contexte doit être transmis au créateur ou à la personne de garde, et toute réponse arbitraire sans fondement est strictement interdite.
Logique de conception : rôles, machines à états, hiérarchisation des connaissances
Comment changer de rôle ?
Au moins quatre catégories de personnes :Créateur(Concrétiser l’expérience au sein des employés),Administrateur(autorisation de gestion, publication, quota),Utilisateur(Attribuer des tâches aux employés numériques),Personne de service(En cas d’exception). Le créateur ne devrait pas disposer par défaut des droits de modification du stock ni de la tarification ; l’utilisateur ne devrait pas avoir accès aux instructions complètes ni aux clés. Les interfaces ouvertes doivent également être hiérarchisées : une clé au niveau du compte permet de gérer les ressources, tandis qu’une clé au niveau de l’employé ne peut que créer des sessions et consulter ses propres traces.
Le SOP utilise une machine à états, ne vous contentez pas d’utiliser uniquement la mémoire de dialogue.
Le langage naturel peut générer un brouillon initial, et l’exécution doit suivre une machine à états : nœud actuel, slots collectés, outils pouvant être appelés, réessais en cas d’échec, nœud manuel. Lorsqu’une tâche est interrompue, il faut pouvoir sérialiser le contexte et reprendre au nœud d’origine. Plusieurs SOP permettent de basculer en temps réel, mais ce basculement doit conserver les informations « d’où l’on vient et quelles informations déjà confirmées ont été apportées », afin d’éviter que l’utilisateur ne remplisse à nouveau les mêmes formulaires. Les versions et les branches doivent être réversibles ; une modification ponctuelle sur le terrain, comme la mise à jour d’un seul mot‑clé, suffit pour mettre en ligne, sans qu’il soit possible ultérieurement d’imputer la responsabilité.
Ne transformez pas les connaissances en un méli-mélo de recherche.
Créez un index navigable par document, chapitre, page et résumé ; commencez par déterminer dans quelle catégorie l’information est susceptible de se trouver, puis localisez le texte original. Structuration des connaissances en compartiments : séparez les références aux politiques, les descriptions de produits, les scripts d’assistance après-vente et les cas exceptionnels ; une recherche ciblée s’avère plus fiable que la recherche par mots-clés sur l’ensemble du corpus. Associez à chaque réponse la source, les règles et le thème métier ; en environnement de test, il doit être possible de voir « pourquoi cette portion a été retenue ». Le débogage de la recherche résout souvent davantage de problèmes que le recours à un modèle encore plus volumineux.
Développement et mise en œuvre : interfaces, isolation, surveillance, validation
Au moment de l’exécution, il est recommandé d’adopter une entrée unifiée afin d’éviter que chaque compétence suive son propre flux, ce qui pourrait entraîner une dérive d’état. La découverte des capacités, l’exécution isolée, l’intégrité des artefacts et le calcul des quotas doivent être effectués à l’exécution, et non sur la base d’accords préalables. Avant de publier une compétence sur le marché interne, procéder à une vérification des autorisations : les en-têtes d’authentification, les variables d’environnement et les informations d’identification de connexion ne doivent pas figurer dans les interfaces de lecture standard.
- Canal d’exécution: Le flux synchrone convient aux conversations ; le Run asynchrone + le flux d’événements est adapté à la reprise après coupure et aux files d’attente de tâches, les deux utilisant le même noyau.
- Identité du canal: WeChat, WeCom, Feishu et DingTalk peuvent servir d’entrée, mais l’identité des employés, les conversations et le trace doivent être unifiés ; il est interdit de créer un système de gestion distinct pour chaque canal.
- Sécurité: La configuration du modèle ne fait référence qu’aux numéros de configurations existantes et ne renvoie pas la clé du fournisseur ; les résultats des outils sont anonymisés lors de leur enregistrement dans le trace.
- Soutien humain de dernier recours: En cas de dépassement du délai, de faible niveau de confiance, d’accès non autorisé ou de transfert manuel vers un agent par l’utilisateur, les quatre conditions doivent permettre une transmission complète du contexte.
La phase de validation ne doit pas se limiter à vérifier que « l’application peut discuter ». Fournissez un ensemble de scénarios répétables : boucle normale, interrogation intermédiaire, solde insuffisant, délai d’attente de l’interface dépassé, écriture non autorisée, réponse refusée en l’absence de source. Pour chaque scénario, vérifiez : la restauration des nœuds, l’écriture correcte des documents, l’intégrité du trace, ainsi que le traitement des exceptions par les personnes concernées. Le taux de réussite des tests aléatoires, le taux de gestion des délais dépassés et le nombre de réponses sans fondement constituent des indicateurs bien plus pertinents que les étoiles de satisfaction pour déterminer l’autorisation de mise en production.
Ordre de mise en ligne : d’abord une phase de travail répétitif
Ne vous lancez pas d’emblée dans la création d’un assistant tout‑en‑un. Choisissez une tâche répétitive quotidienne de plus de trente minutes, comme la rédaction des comptes‑rendus de suivi commercial, le suivi des approbations, les questions‑réponses sur les règlements ou la prévalidation des dépenses ; transformez les étapes d’entrée, de sortie, les droits d’accès et les exceptions en quatre phrases, puis associez‑les à un SOP et à deux ou trois interfaces en lecture seule ou en écriture restreinte. Lorsque les données de référence sont sales et que les nœuds d’approbation manquent de clarté, commencez par corriger les objets et les statuts, puis ajoutez l’exécution intelligente — une fois les données sales automatisées, elles se diffuseront encore plus rapidement dans toute l’entreprise.
Comment savoir si la conception est bien réalisée : l’ancienne méthode consistant à relancer les équipes par groupes et à remplir des tableaux n’est plus le chemin principal ; les comptes rendus, les rappels et les synthèses peuvent être vérifiés par échantillonnage en comparant avec les documents ; les situations difficiles à clarifier font l’objet d’une escalade ; les opérations sensibles sont soumises à une validation, et les journaux de suivi sont consultables. Pour évaluer la qualité du développement, il suffit de regarder…Une fois une même SOP interrompue, peut-on la reprendre ?、Réponse : peut-on renvoyer à la source ?、Le cas limite peut-il passer à la prochaine phase de révision ?. Une fois ces trois points validés, on pourra ensuite élargir les postes, ce qui est bien plus stable que d’ouvrir au préalable de nombreuses interfaces de discussion.
La difficulté technique du système d’employé numérique ne réside pas dans la génération des dialogues, mais dans la transformation des postes, des processus, des connaissances, des outils et des trajectoires en objets logiciels versionnables. Les prompts peuvent être modifiés dix fois par semaine ; une fois que le modèle d’objet se disloque, chaque compétence devra ensuite être développée selon sa propre architecture. Il convient d’abord de faire fonctionner ces sept catégories d’objets ainsi que la machine à états, afin que la mise à niveau du modèle puisse être effectuée sans perturber l’ensemble ; faute de quoi, chaque changement de modèle équivaudrait à un nouveau projet, et non à une simple modification de configuration.