Déployer un chatbot IA en PME tout en gardant la possibilité d’interrompre son fonctionnement

01Définir les limites du pilote et ses conditions d’arrêt

Un pilote ne reste réversible que si le traitement de chaque demande hors périmètre est défini avant l’ouverture. Le chatbot peut recevoir ce type de demande dès son lancement. Il doit alors suivre une règle connue : indiquer qu’il ne peut pas traiter la demande, la transmettre à une personne disponible lorsqu’un tel relais existe ou passer au mode dégradé prévu. Les services cités ici prévoient que l’utilisateur puisse arrêter l’échange ou être orienté vers un agent humain ^[2][10].

Le périmètre du pilote doit définir les demandes admises, celles auxquelles le chatbot ne doit pas répondre et les conditions de transfert. Lorsqu’un service public britannique est externalisé pour la première fois, le Sourcing Playbook recommande de définir dès le cadrage des objectifs mesurables, des critères de réussite et le périmètre du test ^[1]. La résolution autonome, l’abandon, le transfert au relais humain, le temps de traitement et la satisfaction permettent alors de comparer le pilote à une situation de référence et de décider s’il peut être élargi.

Les sources recommandent de tester le système avant son déploiement, puis régulièrement pendant son exploitation ^[3][5]. Dans la séquence proposée ici, la recette intervient avant l’ouverture du pilote. Elle vérifie aussi qu’un incident peut être contenu, que les traces utiles sont protégées, que l’usage peut être interrompu et que les conditions de remise en service sont définies. Le NIST recommande de documenter les exigences, les rôles et les responsabilités de supervision humaine des systèmes déployés ^[8]. Le pilote n’est réellement réversible que si une personne est désignée pour décider de son arrêt.

Cette progression par étapes ne sert pas seulement à suivre l’avancement. Elle évite que le déploiement se poursuive par inertie jusqu’à devenir irréversible. À chaque étape, le décideur doit savoir ce qui autorise la suivante, quel constat impose une correction et qui peut interrompre le pilote.

Chaque décision est consignée dans une fiche courte associée à l’étape concernée. Elle rappelle le périmètre observé, les résultats attendus, les écarts constatés, les corrections qui restent à effectuer et le nom de la personne qui tranche. Un accord oral ne suffit pas : l’étape suivante ne doit pas rendre invisibles les réserves formulées lors de la précédente. Toute condition qui reste invérifiable doit être traitée avant l’ouverture, et non reportée à l’exploitation.

02Tester le périmètre avant d’ouvrir le pilote

Une recette utile part de situations réelles du périmètre retenu. Elle comprend des demandes ordinaires, ambiguës, incomplètes et exclues. Elle vérifie le résultat attendu, la qualité du transfert et les traces nécessaires à l’analyse. Pour un chatbot de PME, elle peut par exemple tester une demande de délai de livraison, une demande incomplète et une réclamation exclue avant toute ouverture aux clients. Le service documenté du Department for Business and Trade a fait l’objet de tests manuels avant sa bêta privée ^[6], sans que ce cas permette de conclure à l’efficacité de ces tests ni de définir le scénario métier d’une PME.

Les critères sont définis avant le test. La résolution autonome désigne une demande admise traitée jusqu’au résultat attendu sans reprise humaine. La non-réponse désigne le cas où le système refuse ou ne peut pas traiter la demande. Le délai de traitement mesure le temps nécessaire pour obtenir une réponse utilisable ou un relais effectif. La satisfaction mesure une perception ; elle ne prouve ni l’exactitude ni l’achèvement.

L’abandon correspond à une interaction interrompue avant d’obtenir un résultat utile. Il y a transfert au relais humain lorsqu’une reprise est demandée, qu’elle aboutisse ou non. Ces définitions empêchent de classer un transfert réussi parmi les résolutions autonomes. Elles empêchent également une non-réponse correctement formulée de disparaître dans une moyenne générale.

À chaque cas de recette correspond enfin une décision. Une erreur reproductible peut bloquer l’ouverture. Une ambiguïté de formulation peut conduire à corriger le contenu ou l’interface. Une demande légitime mais exclue peut justifier un élargissement ultérieur. La décision dépend du rôle assigné au système, non de sa capacité à produire une réponse plausible.

Pour chaque scénario de recette, il est utile de consigner la demande d’origine, le résultat attendu, le résultat obtenu et la décision qui en découle. Le résultat d’un scénario peut être jugé non conforme malgré une réponse correcte sur le fond si celle-ci contourne la règle de transfert. À l’inverse, une non-réponse peut être conforme lorsque le sujet était explicitement exclu et que l’orientation prévue fonctionne. L’évaluation ne porte donc pas seulement sur la qualité apparente des réponses : elle vérifie que le parcours que l’entreprise a choisi d’ouvrir va bien jusqu’à son terme.

03Comparer le pilote à une situation de référence

Sans situation de référence, le tableau de bord décrit l’activité mais ne permet pas de décider. La comparaison doit porter sur des demandes de même nature et sur un résultat équivalent : résolution, transfert ou abandon. Le point de départ peut être le parcours existant, observé avec les mêmes définitions que le pilote.

Le tableau de bord sépare les volumes, la qualité des résultats et les événements qui affectent la maîtrise du service. Il montre la part des demandes admises, les motifs de non-réponse, les raisons d’un transfert au relais humain et les cas abandonnés. Chaque résultat renvoie aux conversations ou aux traces nécessaires à sa vérification, dans les limites de conservation décidées.

Les revues suivent une cadence choisie avant l’ouverture. Une revue est également déclenchée lorsqu’un événement prédéfini survient. Elles réunissent la personne responsable du service, celle qui peut corriger le système et celle qui décide d’une restriction. Chaque revue aboutit à une décision écrite : poursuite inchangée, correction suivie d’une nouvelle recette, réduction du périmètre ou interruption. Les indicateurs examinés doivent permettre de choisir l’une de ces quatre décisions.

La comparaison exige aussi une stabilité de classement. Si un transfert au relais humain était compté comme un succès avant le pilote, puis comme un échec pendant celui-ci, l’écart ne dit rien sur le service. Les mêmes événements doivent donc recevoir les mêmes définitions avant et pendant le pilote. Lorsqu’une définition change, le tableau de bord le signale et reprend la comparaison sur une base commune. Cette discipline est plus utile qu’un volume supplémentaire de mesures dont les catégories varient au fil des revues.

04Organiser le relais humain sans masquer les échecs

Le relais humain doit faire partie du service dès sa conception. Le dispositif précise quand le chatbot propose un relais, quelles informations sont transmises, qui reçoit la demande et quelle solution est prévue si personne n’est disponible. Pour un chatbot de PME en phase pilote, une question hors périmètre peut entraîner une tentative de transfert vers la personne désignée, si elle est disponible. Le service de Network Rail documente ce mécanisme ^[2]. L’utilisateur peut également demander à interrompre l’échange ou à parler à une personne. Ces deux possibilités sont documentées dans un service existant ^[10], sans que les résultats observés puissent être transposés à une PME.

La réussite du relais ne doit pas effacer l’origine du transfert. Une reprise humaine provoquée par une réponse erronée signale un défaut différent d’un transfert prévu dès la conception. Le standard britannique de transparence demande d’ailleurs de détailler les possibilités de contrôle humain ^[9]. Cette exigence porte sur la description du dispositif et ne détermine pas l’organisation propre à l’entreprise.

Ce tableau distingue le résultat observé de la décision à prendre.

La responsabilité ne se résume donc pas à surveiller un écran. Une personne reçoit les alertes, une autre peut appliquer la correction et l’autorité habilitée à interrompre le service est désignée. Le NIST recommande précisément de documenter les exigences, les rôles et les responsabilités liés à la supervision des systèmes déployés ^[8].

Le test du relais doit inclure son indisponibilité. Une demande correctement transmise mais déposée dans une file que personne ne consulte n’est pas une sortie maîtrisée. La recette vérifie donc le destinataire, le délai à partir duquel un autre parcours s’applique et l’information donnée à l’utilisateur. Elle vérifie aussi les informations transmises à cette personne : le motif du transfert, les éléments déjà confirmés et le point qui exige son intervention. Ce test porte sur la continuité du service, pas seulement sur le bouton de transfert.

05Distinguer les incidents, les dérives et les conditions de reprise

La surveillance doit distinguer les écarts qui appellent une correction, une restriction ou un arrêt. Les contrôles réguliers complètent alors les tests préalables ^[3][5]. Ces contrôles portent sur les motifs de non-réponse, les transferts au relais humain, les résultats incohérents et les traces devenues inexploitables. Chaque écart est comparé au périmètre autorisé et à la situation de référence afin d’en évaluer les conséquences sur le service.

1. 01

   Détecter l’écart

   Une alerte, une revue ou le signalement d’une personne permet d’identifier le comportement à examiner.

2. 02

   Qualifier l’effet

   Le responsable distingue un défaut isolé, une dérive répétée et un incident qui affecte le service.

3. 03

   Limiter le périmètre concerné

   La règle prévue sert à restreindre, selon le cas, une fonction, un périmètre ou un accès.

4. 04

   Protéger les traces

   Les éléments nécessaires à l’analyse restent accessibles aux personnes autorisées.

5. 05

   Activer le mode de repli

   Selon la situation, le mode dégradé est activé ou la demande est transmise à une personne disponible.

6. 06

   Valider la remise en service

   La correction est testée avant une remise en service limitée et surveillée.

L’arrêt doit permettre d’atteindre un état sûr. Pour les systèmes à haut risque, l’article consacré à la supervision humaine prévoit qu’une personne puisse intervenir ou interrompre le fonctionnement au moyen d’une procédure permettant d’atteindre cet état ^[7]. Cette obligation ne signifie pas que tout chatbot de PME est automatiquement un système à haut risque. Dans le champ d’application de cet article, elle précise ce qu’une procédure d’interruption doit permettre.

La remise en service doit reposer sur des critères écrits : la cause est comprise, les conséquences sont contenues, la correction est éprouvée, les traces sont disponibles et le responsable a donné son accord. Le service reprend sur un périmètre limité. Si les conditions initiales ne sont plus valables, le pilote revient à une étape antérieure au lieu de se poursuivre sur une hypothèse devenue fausse.

06Décider de généraliser, de limiter ou d’arrêter le déploiement

La dernière revue examine de nouveau l’objectif déclaré. Le NIST recommande de déterminer si le système atteint sa finalité et si son développement ou son déploiement doit se poursuivre ^[4]. Cette décision compare les résultats à la situation de référence, examine les échecs qui subsistent et vérifie que le relais humain, la limitation du périmètre et la remise en service fonctionnent encore dans les conditions observées.

Si les résultats permettent de poursuivre, l’extension suivante reste limitée au périmètre testé et aux contrôles associés. Après toute correction qui modifie le comportement attendu, la recette doit être rejouée avant toute nouvelle ouverture. Un objectif non atteint ou des résultats mal maîtrisés justifient de ne pas élargir le déploiement. La généralisation constitue un nouveau test : l’ajout d’usages, d’utilisateurs ou de situations peut modifier les résultats et impose donc une nouvelle phase limitée.

Élargir le nombre d’utilisateurs sans changer les usages n’appelle pas la même vérification qu’ajouter un nouveau type de demande. Le premier changement met surtout à l’épreuve la charge, la disponibilité du relais et la capacité de surveillance. Le second modifie les réponses admises, les exclusions et parfois les données nécessaires. Une décision de généralisation qui regrouperait ces deux changements empêcherait d’identifier la cause d’un éventuel écart. Chaque extension doit donc préciser ce qui change, ce qui reste acquis et l’étape à laquelle revenir si les résultats se dégradent.

La suite peut nécessiter une conception et un cadrage d’assistants conversationnels afin de réunir, dans un dispositif exploitable, le périmètre, les données autorisées, les règles de transfert et les responsabilités. Cette démarche devient utile une fois les critères de décision définis. Il ne remplace ni la recette ni la personne autorisée à interrompre l’usage.

Avant toute extension, l’entreprise doit vérifier qu’elle saura détecter un résultat indésirable, en limiter les effets, assurer un relais humain ou activer un mode dégradé, puis décider d’une reprise. Si la réponse reste ambiguë, le déploiement ne doit pas être élargi. Si la recette, les traces et l’attribution des responsabilités montrent que ces conditions sont réunies, l’étape suivante peut être engagée tout en conservant la possibilité de revenir en arrière.