Cas synthétique TPE — De la boîte mail au copilote validé

Exemple fictif. L’entreprise, les personnes, les volumes et les résultats sont entièrement synthétiques. Ils illustrent la méthode ; ils ne constituent ni une étude de marché, ni une preuve de performance, ni un avis juridique.

1. Situation initiale

Atelier Horizon est une TPE fictive de huit personnes qui installe et entretient des équipements pour des clients professionnels. Une boîte mail partagée reçoit environ 360 demandes par mois : devis, rendez-vous, pannes, questions de facturation et réclamations.

Deux personnes lisent les messages, cherchent les informations dans les documents internes, choisissent le bon responsable et rédigent une réponse. Les demandes ambiguës ou incomplètes circulent parfois entre plusieurs membres de l’équipe.

Baseline mesurée sur quatre semaines

Le problème retenu n’est pas « automatiser le service client ». Il est plus étroit : préparer une attribution et un brouillon utiles, sans envoyer ni modifier un système sans validation humaine.

2. Mandat et limites

Interdictions écrites avant le choix de l’outil

• aucun envoi automatique ;
• aucune promesse de prix, délai, garantie ou indemnisation ;
• aucune modification du CRM ou du planning ;
• aucune utilisation de données bancaires, médicales ou étrangères au cas ;
• aucune réponse lorsque l’identité, le destinataire ou la demande restent ambigus ;
• aucun apprentissage fournisseur sur les données de l’entreprise sans accord vérifié.

La procédure manuelle reste disponible pendant tout le pilote. Un utilisateur peut retirer le copilote du flux sans interrompre la boîte mail.

3. Architecture suffisante la plus simple

L’équipe compare trois options :

1. ajouter des règles de messagerie et des modèles de réponse ;
2. combiner un routage déterministe avec un modèle qui extrait les informations et prépare un brouillon à partir de contenus approuvés ;
3. utiliser un agent connecté à la messagerie, au CRM et au planning.

L’option 2 est retenue. Les règles classiques traitent les expéditeurs connus, les numéros de contrat et les catégories stables. Le modèle reçoit un message minimisé, propose une catégorie, liste les informations manquantes et prépare un brouillon. La personne voit le message original, les sources utilisées et la proposition dans le même écran.

L’option agentique est rejetée : elle ajoute des permissions et des effets sans être nécessaire au résultat recherché.

4. Évaluation préenregistrée

L’équipe constitue 80 demandes historiques autorisées et minimisées. Quarante servent à régler le système ; quarante sont gelées pour la décision. Le jeu de décision contient des demandes courantes, des informations manquantes, des réclamations, des données à protéger, un mauvais destinataire et des instructions malveillantes placées dans le corps du message.

Résultats sur le jeu gelé

Deux brouillons contiennent une formulation trop affirmative, mais aucune promesse de prix, de délai ou de garantie. Ils sont conservés dans le registre d’erreurs et ajoutés aux tests de non-régression.

5. Pilote en deux paliers

Jours 15 à 21 — Shadow mode

Le copilote traite les nouveaux messages sans montrer ses propositions aux personnes qui répondent. Une évaluatrice compare ensuite la catégorie, les informations extraites et le brouillon au traitement réel. Un changement de configuration est autorisé pendant cette phase ; chaque version est notée.

Jours 22 à 30 — Copilote

Trois utilisateurs formés voient la proposition. Ils doivent accepter, corriger ou rejeter l’attribution et le brouillon. Le bouton d’envoi reste celui de la messagerie et exige toujours une action humaine. Les réclamations, les demandes financières et les messages ambigus sont systématiquement escaladés.

6. Résultats observés

Le palier copilote porte sur 90 demandes consécutives. Les résultats sont comparés à la baseline, sans extrapolation annuelle.

Les demandes incomplètes et les références produit inhabituelles concentrent les corrections. Le gain observé reste compatible avec l’ordre de grandeur des études de terrain disponibles, sans être présenté comme une réplication. L’absence d’incident grave sur 90 demandes ne démontre ni que le risque est nul, ni que son taux est faible.

7. Décision de gate

Décision : continuer sous conditions au niveau copilote.

La valeur métier et les seuils de fiabilité sont atteints sur le périmètre observé. L’équipe n’autorise toutefois ni envoi automatique, ni écriture dans le CRM, ni modification du planning.

Conditions pour les 60 jours suivants :

1. ajouter 20 cas sur les références inhabituelles et les informations manquantes ;
2. maintenir une revue hebdomadaire des erreurs et quasi-incidents ;
3. répéter le jeu gelé après chaque changement de modèle ou d’instructions ;
4. surveiller séparément temps, qualité, corrections et escalades ;
5. revoir le fournisseur, les coûts et la possibilité de sortie après 60 jours.

Une automatisation bornée ne sera examinée que si un sous-ensemble stable, réversible et vérifiable dépasse les seuils sur une période plus longue.

8. Ancrage dans des cas publiés

Le scénario reprend des mécanismes observés, mais aucun chiffre d’une autre organisation n’est réutilisé comme résultat du pilote fictif :

• le cas de la PME croate RIS décrit la classification des courriels, la recherche dans une base interne et les brouillons relus par les agents ; les gains annoncés sont des estimations de cas de succès, pas un benchmark indépendant ;
• une étude publiée dans le Quarterly Journal of Economics sur 5 172 agents de support mesure un gain moyen de productivité de 15 %, très variable selon l’expérience et les problèmes traités ;
• un cas industriel maritime montre que les brouillons peuvent accélérer le travail tout en exigeant souvent des modifications importantes ; les experts doivent garder la décision finale ;
• une expérience menée dans 66 organisations observe moins de temps passé dans la messagerie chez les utilisateurs actifs, sans transformation détectable de la structure globale du travail ;
• des cas publiés par l’OCDE et Microsoft montrent l’importance des échanges par courriel, de la rapidité de réponse et de la qualité linguistique, mais ne permettent pas d’inférer les performances d’une TPE suisse.

Les liens, chiffres publiés et limites de transfert sont consignés dans la note de preuves des cas.

9. Dossier de preuves

Le pilote conserve :

• le mandat et la baseline ;
• la fiche de cas d’usage ;
• l’évaluation du fournisseur ;
• le plan d’évaluation et le jeu gelé ;
• les versions de configuration et le registre d’erreurs ;
• la décision de pilote ;
• le runbook d’incident et la procédure manuelle testée.

Ce dossier permet à une autre personne de comprendre pourquoi le pilote a été autorisé, ce qui a réellement été observé et quelles actions restent interdites.