Ce qui n'a pas marché, et ce que j'en ai retenu

On raconte volontiers ce qui marche. Voici ce qui n'a pas marché, ou pas encore, depuis que je confie une partie de mon travail à l'IA. Ces échecs m'ont appris davantage que les réussites. Ce sont eux qui ont fixé les règles que j'applique à chaque nouvel agent.

Un agent vocal mis en pause

Chez Oliverlist, l'agent vocal pour les appels clients est en pause. Je préfère le dire clairement : ce qui marche à l'écrit ne se transpose pas toujours à la voix.

À l'écrit, l'IA prépare et une personne peut relire avant l'envoi. Un e-mail mal tourné se corrige avant de partir. Au téléphone, chaque phrase part en direct. Il n'y a ni brouillon ni relecture, et pas de seconde chance sur la première impression.

Une conversation se joue aussi sur ce qu'un e-mail n'a pas : le ton, une hésitation, une interruption, un silence. Et quand un agent parle au nom d'un client, ce client doit être à l'aise avec chaque mot prononcé.

L'écrit a un autre avantage : tout est tracé. On peut relire une semaine d'échanges en une heure et voir où l'agent se trompe. Réécouter des appels prend bien plus de temps.

Ce que j'en retiens : commencez par les canaux écrits, où une validation humaine reste possible avant d'agir. Et prévoyez dès le départ un interrupteur. Mettre un agent en pause n'est pas un aveu d'échec. C'est une fonction qu'il doit avoir.

Trop d'alertes tuent l'alerte

Chez Oliverlist, Sorter classe chaque réponse de prospect toutes les 5 minutes. Une réponse jugée chaude crée une tâche pour l'équipe. Le problème : le tri en signalait trop qui ne l'étaient pas. Chaque fausse alerte coûte un peu d'attention, et l'attention s'use. Une alerte souvent fausse finit par être ignorée, y compris le jour où elle est juste.

J'ai repris les consignes du tri ces derniers jours, et la mesure est en cours. Mais la leçon dépasse ce cas. Réduire les fausses alertes ne doit jamais faire rater les vraies. Il faut donc compter les deux, les fausses alertes et les cas manqués, avant et après chaque changement. Pour les cas manqués, il n'y a pas de raccourci : il faut relire un échantillon de ce que le tri a écarté.

Une autre question aide à séparer l'alerte du reste : que doit faire, maintenant, la personne qui la reçoit ? Si la réponse est « rien, c'est pour information », ce n'est pas une alerte. C'est un rapport, et sa place est ailleurs.

Les contrôles de nuit doivent suivre la même règle : seules les anomalies remontent. Un contrôle qui signale tout ne signale rien.

Des contrôles que personne ne lisait

J'ai aussi construit des contrôles que personne ne lisait. Un rapport que personne n'ouvre ne contrôle rien. Il donne seulement l'illusion d'être couvert.

Le piège est facile à comprendre. Construire un contrôle ne prend que quelques minutes. On en ajoute un à chaque inquiétude, sans jamais en retirer, et le rapport grossit jusqu'à ce que plus personne ne l'ouvre.

Un contrôle utile réunit trois choses : un destinataire nommé, un seuil, une action attendue. L'alerte doit arriver là où la personne travaille déjà, avec le détail à un clic, plutôt que dans un tableau de bord qu'il faut penser à ouvrir. C'est ainsi que fonctionnent désormais mes agents : ils écrivent directement aux personnes concernées.

Un test simple, à faire chez vous : pour chaque rapport automatique, demandez qui l'a lu la semaine dernière et ce qu'il en a fait. Si personne ne sait répondre, changez son destinataire ou supprimez-le. Un contrôle sans destinataire est un coût, pas une sécurité.

Des effets encore en cours de mesure

La couche que je construis depuis juillet n'a que quelques mois. Ses effets sont mesurés par endroits, pas partout. Pour certains agents, je ne sais pas encore dire s'ils font gagner du temps, de l'argent, ou rien du tout. Je préfère l'écrire plutôt qu'afficher un chiffre fragile.

Construire prend des jours, mesurer prend des semaines. Il faut un point de départ, un volume suffisant, et de quoi isoler l'effet de l'agent de tout ce qui bouge en même temps : la saison, les campagnes, l'équipe. Si vous ne notez pas la situation de départ avant de lancer, vous ne pourrez jamais prouver l'effet, ni dans un sens ni dans l'autre.

Concrètement, avant de lancer un agent, notez trois choses : le volume traité aujourd'hui, le temps que cela demande et à qui, et le taux d'erreur actuel quand il est mesurable. Ce sont trois lignes dans un document. Sans elles, vous débattrez de l'effet de l'agent au lieu de le constater.

À retenir

Avant de lancer un agent, prévoyez cinq choses.

1. Une validation humaine là où l'erreur coûte cher : l'argent, les clients, les personnes.
2. Des audits : relire régulièrement un échantillon des décisions de l'IA, et compter ses erreurs.
3. Une surveillance : chaque agent signale ses propres échecs. Une exécution qui échoue en silence est le vrai danger.
4. Un interrupteur : pouvoir arrêter un agent sans rien casser, comme je l'ai fait pour la voix.
5. Une mesure fixée avant de construire : le chiffre qui doit bouger, et sa valeur de départ.