Ce qui rate quand on automatise, et pourquoi ça ne se voit pas

Un chef d’entreprise m’a montré un jour la checklist d’entretien qu’il avait fabriquée avec une IA. Quatre cents cases. Un travail impressionnant, produit en quelques minutes, et parfaitement inutile : il ne s’en servait pas.

Ce n’était pas une mauvaise checklist. C’était une liste que personne ne pouvait finir. Et une liste qu’on ne finit jamais apprend à ne pas cocher.

Cette histoire dit déjà l’essentiel de ce qui suit. Quand on automatise, on imagine que l’échec sera visible : un message d’erreur, un écran rouge, quelque chose qui s’arrête et qu’on remarque. Dans la réalité, une automatisation qui rate ne fait aucun bruit. Elle continue d’exister, elle ne produit simplement plus rien, et l’absence de résultat ressemble exactement au fonctionnement normal.

Voici quatre pannes réelles, relevées pendant l’installation d’un système chez un client qui pilote plusieurs sites et plusieurs intervenants. Aucune n’était prévisible depuis un bureau. Aucune n’a produit la moindre alerte.

Trois jours sans rien, et personne ne l’a vu

Le système devait créer chaque jour les tâches à faire : préparer un lieu, contrôler avant une arrivée, faire un ménage. Pendant trois jours, il n’a rien créé du tout. Aucune tâche, pour aucun lieu.

Personne ne s’en est aperçu. Pas parce que le client était négligent, mais parce qu’un système qui ne crée pas de tâche ressemble en tous points à une journée sans tâche à faire.

La cause était humaine, pas technique. Le client avait une réservation qui portait sur trois espaces à la fois, et il les avait écrits dans une seule cellule, séparés par des plus. Le système attendait une valeur connue, il en a reçu une qu’il ne connaissait pas, et il s’est arrêté. Non pas pour cette ligne : pour toutes.

Et le vrai coupable est ailleurs. Son mode d’emploi lui disait « une ligne égale une réservation ». Il ne disait nulle part comment écrire une réservation qui porte sur plusieurs espaces. Le client a donc fait ce qui lui semblait logique.

La documentation qu’on laisse dicte la saisie. Quand quelqu’un remplit un tableau d’une façon qui casse le système, ce n’est presque jamais qu’il a mal lu. C’est que la situation n’était pas décrite.

Le lieu que le système ignorait

Le même client avait plusieurs espaces. Vingt-deux tâches récurrentes avaient été configurées, et elles étaient toutes rattachées au premier. Un des lieux n’en avait aucune.

Une réservation sur ce lieu-là n’aurait donc produit aucune tâche. Pas d’erreur, pas d’alerte, pas de ligne vide à repérer. Rien. Le ménage n’aurait simplement pas été demandé, et personne ne se serait demandé pourquoi.

Nous l’avons trouvé par accident, en saisissant une réservation de test au mauvais endroit.

C’est le point le plus important de cet article : il existe des endroits, dans tout système automatisé, où l’absence de résultat est indiscernable d’un fonctionnement correct. Ce sont ceux-là qu’il faut chercher, et on ne les trouve pas en vérifiant que ça marche. On les trouve en vérifiant que ça marche partout.

Ça marchait chez moi

Le système donnait à chaque intervenant un lien personnel, à ouvrir sur son téléphone, pour voir ses tâches du jour et signaler ce qui était fait. Testé, validé, fonctionnel.

Sur place, chez le client, quatre de ces liens ne s’ouvraient pas. Le déploiement était pourtant correct : ils s’ouvraient parfaitement sur mon écran.

La différence tenait à un détail que rien ne pouvait laisser prévoir. Il ouvrait ces liens depuis une application, sur un téléphone où plusieurs comptes étaient connectés, et ce n’était pas le bon compte qui prenait la main. Depuis un navigateur, tout fonctionnait.

Un déploiement ne se juge jamais depuis l’ordinateur de celui qui l’a fait. Celui qui installe travaille sur une machine où tout est déjà connecté, configuré, à jour. Les gens qui vont s’en servir, non. Ils ont d’anciens téléphones, plusieurs comptes, des applications qui interceptent les liens. Tant qu’un système n’a pas été ouvert par la personne qui l’utilisera, sur son appareil à elle, il n’est pas testé.

Mon erreur, en séance, devant le client

La quatrième panne est la mienne, et je la raconte parce qu’elle est instructive.

Nous étions ensemble. Il avait saisi ses informations dans le système : ses lieux, les prénoms de ses intervenants. J’ai voulu appliquer une correction, et pour aller vite, j’ai remplacé le programme complet par sa version corrigée.

Sa saisie a disparu. Le nouveau programme portait sa configuration d’origine, vide, et elle a écrasé la sienne.

Rien de grave : quelques minutes à ressaisir, et c’était réparé. Mais c’était devant lui, et ça n’aurait pas dû arriver.

Une correction complète ne se fait pas devant un client. On isole la partie à changer, ou on attend d’être seul.

Depuis, un questionnaire de cadrage détaillé recueille ces informations bien en amont de la séance, ce qui rend l’incident nettement moins probable. Nettement moins, pas impossible : c’est le genre de raccourci qui reste tentant quand quelqu’un attend en face de vous de voir le résultat.

Ce qu’on met en face

Ces quatre pannes n’ont rien en commun techniquement. Elles ont tout en commun autrement : aucune n’a produit de signal.

C’est la vraie leçon d’une installation. Un système automatisé n’a pas besoin de vous dire ce qu’il fait quand tout va bien, personne ne lit ces messages-là. Il doit vous dire quelque chose quand il ne fait rien.

Concrètement, trois questions à poser avant de considérer qu’une automatisation est en place :

Comment je saurai qu’elle s’est arrêtée ? Si la seule réponse est « je m’en rendrai compte », alors vous ne vous en rendrez pas compte. Il faut une trace visible : un relevé du matin, un compteur, un endroit où l’on voit que quelque chose s’est produit hier.

Est-ce que je l’ai testée partout, ou seulement là où je l’ai construite ? Chaque lieu, chaque cas, chaque personne. Les endroits qu’on ne teste pas sont exactement ceux qui échoueront en silence.

Est-ce que quelqu’un d’autre que moi l’a ouverte, sur son matériel ? Pas une capture d’écran, pas une démonstration. La personne, son téléphone, son compte.

Ce ne sont pas des questions techniques. Ce sont les questions qui décident si vous avez installé un outil ou une illusion d’outil.

Et pour revenir à la checklist de quatre cents cases : le problème n’a jamais été qu’elle était mal faite. Le problème, c’est que personne n’avait regardé comment le travail se faisait vraiment avant de fabriquer l’outil qui allait le remplacer.

Si vous envisagez d’installer de l’IA dans votre activité, voici comment je travaille.